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Chapter 1 

Becoming an Accidental Project 
Manager 1 

1.1 Congratulations... you're the project manager! 

note: The following is based on, and adapted from, the premise of The Education of Jerry by J. 
Davidson Frame in Managing Projects in Organization, John Wiley, New York (1995). 

John picks up the phone before the second ring. It's his boss, Mike Johnson. "John, I'd like you to stop by 
my office right after lunch today." 

John is not really sure why the boss is calling him into his office, which makes for a long lunch hour. 
He knows he's been doing a good job lately. As a matter of fact, he knows that he's probably the most 
technically capable person in the group. John's mind begins to race. . .. Maybe it's an award? Could it be a 
promotion? Countless positive and negative scenarios run through John's overworked mind until one o'clock 
finally rolls around and he cautiously enters Mike's office. 

"John, I've got some great news for you," Mike begins. "As you know our company is developing 
a business-to-business (B2B) e-commerce system. As part of that initiative, I'd like you to explore the 
possibility of integrating our purchase order process into the B2B e-commerce system." 

Before John could say anything Mike continued, "Congratulations, John, I'm assigning you as the project 
manager. Use anyone you need to help you; the important thing is to give me a report on your findings 
within a month. Your preliminary investigation will give us an idea of how we should go about computerizing 
the order processing function at BizNex Inc., and we need that information in time for our next quarterly 
executive meeting." 

John was delighted with being made the project manager. The B2B project was the largest BizNex Inc. 
had ever implemented, and the order processing subproject was one component of the larger B2B project. 

Once developed, the B2B system would enable BizNex Inc. to establish seamless connections with 
its vendors. Although BizNex Inc. already used computers in its order processing system, the bulk of 
transactions entailed manual interventions. This caused the order fulfillment function to operate slowly and 
led to errors because the manual interventions were error prone. With the new B2B system, customers 
would enter orders using the internet. Once captured by the B2B e-commerce system, the orders would be 
processed entirely by the computer. 

This project provided John with his first real management experience. He was hired by BizNex Inc. 
straight after completing his MBA degree at Rice University. During his first two years at BizNex Inc., he 
was assistant to Mike Johnson, Vice President of Operations. Despite the high profile of his job and the 
exposure it gave him to high-level decision making within the company, John felt that he wanted to become 
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2 CHAPTER 1. BECOMING AN ACCIDENTAL PROJECT MANAGER 

more involved in the decision making process. With the order processing subproject, he was being given 
something tangible to do with significantly more responsibilities. 

John determined to do a good job on his project. He put together a task list. From his experiences since 
leaving college he knew it was important to assemble the "Project Staff." After careful thought he decided 
he needed a business analyst, a procurement specialist, an internet expert, an e-commerce expert, a logistics 
expert, and a representative from each of the company's five divisions. He figured that he and the business 
analyst would be the only full time resources on the project. However, the other team members would need 
to make a fairly substantial commitments to the project if it is to be completed in a month. He decided that 
each would have to dedicate 25% of their time to the project. 

Since there would be five divisions represented, John planned that each of the five divisional represen- 
tatives would write a section of the study, detailing the impacts of the order processing system on their 
operations and defining whatever order processing needs they have. The business analyst would capture and 
document the business requirements and write the technical portions of the report. John's function would 
be to coordinate the efforts of the others and to integrate all the pieces into a cohesive plan. 

As John started to put his team together, he immediately ran into trouble: he was unable to get a business 
analyst assigned full time to the project. Because his division was in the midst of developing the B2B system, 
all business analysts were already over committed. John went to his boss, Mike, with his problem, but was 
simply told that he would just have to make do with the resources available on a day-to-day basis. 

John thought his luck was changing when he tried to obtain the procurement specialist for his project. 
After several enquiries someone told him he should talk with Doug Black, who worked in the contracts and 
procurement department. Doug was two months away from retirement so his workload was being reduced. 
John reasoned that one month assignment on his project would fit in with the plans to ease Doug into 
retirement. As a consequence Doug was assigned full time to the project to help pick up the slack of not 
have a business analyst on the project. 

John next approached the information resource manager located in the Information Technology division 
and told him of his need for an internet specialist and e-commerce expert. The resource manager immediately 
assigned Sara Stone to help John with internet matters. Unfortunately, with no internal e-commerce system 
experience, John was told that he would have to go to an outside consultant for the e-commerce expertise 
needed. 

The varying degrees of success John had had so far continued when he tried to recruit the representatives 
from the different divisions. The vice president of the information technology (IT) division, Sam Nelson, 
was nothing like what he hoped for. His request for assistance was met with an uncomfortable silence. A 
clearly upset Sam said, "I don't fully understand why you and Mike are playing the lead role on something 
like this. Building an order processing system is basically an information technology chore and should be 
left to the IT experts. I've had my team looking into the matter of automating the order processing system 
for months, and now you come in here telling me what to do." He dismissed John saying that he would 
"look into things personally." John noted that he had specifically not indicated that he would provide any 
cooperation. In contrast, John had a good reception from the finance division; the vice president of finance, 
Lynn Waters, announced it was about time BizNex Inc. entered into the twenty-first century and said she 
would be glad to assign someone from her office to help John on the project. 

Until now, all of his experience at BizNex Inc. had been quite friendly, this was a side of the business 
he had not seen before. As he got back to his office, he didn't have any time to consider the implications 
because Doug Black knocked on his door. 

"Listen John," Doug said rather sheepishly. "As you know, I have just under two months until I am out 
of here. I'd like to help you on this project of yours, really I would. I am sure it is important. But let me 
say I really don't know much about computers and think order processing is horridly dull. I don't see why 
I should put too much effort into something that won't effect me. So while I'll work with you, you won't 
expect too much will you?" 

All of this happened on the Thursday, just three days into the project. To get the project moving, John 
tried to arrange a kick-off meeting of all project staff at nine o'clock the following Monday. Since Sam 
Nelson's office (IT) had not assigned a representative, it would not be represented. The finance division 



representative said he thought it was a great idea, but he would be out of town throughout the week so 
could not attend. The other project staff members said they would attend the meeting, but John got the 
impression they were not happy about it. Only Sara Stone, the internet expert, sounded interested. John 
wasn't sure what he would do about getting the e-commerce expert. He would have to talk to Mike Johnson 
about it. 

All through the weekend, John prepared for the meeting. He put together a five page preliminary position 
paper, identified milestones the team members would have to meet, created guidelines for the activities to 
be undertaken and read several journal articles on Internet Technology and online order processing. On 
Monday at nine o'clock, John arrived in the conference room and found it empty. By nine-thirty, only two 
other project team members had shown up. Conspicuously absent were Doug Black and Sara Stone, both 
of whom had assured him they would be there. 

Without accomplishing anything, John closed the meeting and returned to his office. On his voicemail 
he found a message from Sara Stone saying that she was sorry to have missed the meeting, but her boss in 
the information resources management department (part of the IT division) had told her that he was pulling 
her off the project. 

About an hour later, Mike Johnson called John into his office to tell him that he was putting the order 
processing automation project on hold. He said, "Sam went to the CEO and complained that you and I are a 
couple of cowboys, and were running around doing things we had no business doing." Mike seemed resigned, 
and continued, "Sorry John. You win some and lose some. Next time we'll do better right?" 

John mumbled assent then went back to his own office. Closing the door he sat at his desk and stared 
out of the window. What had he done wrong, and why had someone told the company CEO that he was 
some kind of amateur. As the implications of this last week settled in, John wondered about his future with 
BizNex Inc. 

1.2 So what went wrong? 

The story above is not an isolated incident. Every day, scientists, engineers, salespeople, technicians, and 
countless others are thrust into the role of project manager. They're very good at what they do. In fact, 
they're typically the most technically knowledgeable engineers or the most successful salespeople. Now 
they're about to become project managers. 

Actually it's probably appropriate to refer to them by their more popular name: accidental project 
managers. An accidental project manager is a person who is placed into the role by organizational necessity 
and chance, rather than by design or through choice of career path. 

If you're an accidental project manager, one of the first things you should do is pause to consider whether 
or not you're cut out to be a project manager and try to determine whether it's what you really want to do. 
Why? Because if you do a reasonably good job leading your first project, chances are you'll be asked again. 
And again. And again. In other words, if you're finding yourself in the same position as John, you might 
be embarking upon a new career. You'd be wise to consider some of the pros and cons before saying yes to 
that career move. 

The information, tools, and techniques described in this course will move you well along in understanding 
the mechanics of managing projects. But it's important that you enter this new world with your eyes wide 
open. With that thought in mind, let's take a closer look at what you might expect to experience as a project 
manager. 

However John may feel about taking on his first project, the truth is that life as a project manager can 
be extremely rewarding. You'll find it to be different from almost any other thing you've ever done. It's 
complex, varied, and interesting. If done well, it can lead to a very strong sense of accomplishment. These 
are among the aspects that project managers identify as the main draws to the job. 

At the same time, being a project manager will test you in ways you may not be able to imagine. You 
will become a focal point in the organization especially on high profile projects. Everyone will look to you 
for the answers, but you must be careful not to try to provide all the answers; after all, that's why you have 
a team. 
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Speaking of the team, one of the biggest shifts in behavior (and thinking) you'll encounter will be the need 
to rely upon others to get things done. In most cases, that's your team. You'll quickly discover that there's 
far too much for you to do alone, yet delegation will prove to be a challenge for you. Empowering others, 
and then trusting them to follow through, may be a bit unsettling. You'll find yourself uncomfortable with 
the idea that others are doing things for which you will be held responsible. You'll have lots of responsibility, 
but you'll be missing the authority often perceived as being required to discharge that responsibility. 

John was given the responsibility for getting the job done but had very little authority to see to it that 
his decisions were implemented. This was reflected in his problems in recruiting project team members and 
evidenced in the fact that he could exercise only marginal control over Doug Black, the procurement specialist 
and the only other full time member. Project professionals typically have little authority to carry out their 
work. They have little or no direct control over those people and things that make the difference between 
project success and failure. Among your most valued tools will be the ability to persuade and influence, as 
you seek to form a group of diverse personalities into a unified team with commonalty of purpose. 

Unfortunately, not everyone on your team will be as knowledgeable and skilled as you would like. Nonethe- 
less, you've got to get the job done using whatever resources have been provided. Project manager's staff is 
generally on temporary loan to them. This is also true of the material resources needed for the success of 
the project. People with specialized skills often work on the individual pieces. 

On the B2B sub-project in this story, the team was structured in such a way that most of the members 
would bring their own specialized skills to the project, e.g., knowledge of e-commerce, knowledge of the 
workings of the procurement division, internet /technical skills. Often, though, skills are so specialized that 
they are employed only briefly. It is not at all uncommon to have the composition of the project team 
continually changing as the project progresses through its life cycle. 

So as long as project professionals are dealing with borrowed resources, they have limited control over 
them. This reality overwhelmed John. The case study is full of instances in which he was incapable of 
getting people to do what he needs to have done. 

• He couldn't get a business analyst assigned full time to his project. 

• His full time resource, Doug, made it clear that he is just treading water until his retirement and 
doesn't even show up for the kick off meeting. 

• Jerry finds a competent colleague in Sara Stone, the internet expert; but due to the political dynamics 
of the situation, she is pulled off the project by her boss. 

• BizNex Inc. doesn't have an e-commerce expert so he will have to hire an outside consultant over 
whom he may not be able to exercise some degree of control. 

From John's perspective, the problem is that although he is the project manager, he is not the boss. This 
would be highly impractical, to be boss, John would have to possess control over the career development of 
all the people on working on the project, and in view of the nature of his small project, highly impractical. 

Project management lore is full of tales of project managers who were able to take the hand that was 
dealt and turn it into project success. For you to succeed, you'll have to rely on your ability to coach, mentor, 
and motivate, in order to get the level of performance you need from those assigned to work on your project. 

What will you have to know as a project manager? Well, you'll have to know a little bit about just about 
everything. You'll have to learn to pay attention to the details, but not get wrapped up in them. You'll 
have to make countless decisions with insufficient information and despite conflicting signals. You'll have 
to condition yourself to seek acceptable solutions, rather than perfect ones. You'll have to blend technical 
expertise with a keen sense of human nature. You'll have to handle administrative matters. 

While you're busy doing your own thing, you'll have to cultivate and maintain a smooth working relation- 
ship with many other people, both inside and outside your organization. Unfortunately, as you seek to carry 
out the objectives of the project, it's unlikely that everyone you encounter will be an ally. Organizational 
politics and reality dictate that not everyone will like project management or project managers (that's you!). 
Many people will admire your role, respect your position, and appreciate your involvement; others will not. 
You will need to figure out who's who, really fast. 



One final word on John's unfortunate adventure; a substantial share of his problems are rooted by his 
lack of experience. For example, he does nothing to strengthen his authority. Rather than go out on his 
own in dealing with people in other departments at BizNex Inc., he should have worked through his vice 
president, Mike Johnson. He could have drafted an e-mail, sent by Mr. Johnson that explained the purpose 
of his inquiries. In this way, he would not have looked like a loose cannon. Because John dealt directly with 
vice presidents in the company, it isn't really surprising that the information technology vice president saw 
John's actions as an infringement on his territory. 

Project management is both an art and a science. The art is strongly tied to the interpersonal aspects; 
the business of leading people. The science includes understanding of processes, tools and techniques. All 
project managers are expected to be very well versed in the science of project management. You cannot 
survive without being knowledgeable in this area. 

We will be addressing the overall project context, encompassing people, teams and the organization. 
We'll look at how organizational issues can lead to project success or failures and the central importance 
of politics in projects. We'll talk about strategies on how to cope with these and other realities. We'll talk 
about project planning and control and defining the needs and requirements analysis, we'll review some 
standard tools used for enhancing planning and control and finally how to successfully close out a project. 

Although we'll focus primarily upon the process, we'll never lose sight of the importance of the interper- 
sonal aspects as well as the environmental aspects; the people and things that surround your project. 

1.3 Bibliography 

• J. Davidson Frame, Managing Projects in Organization, John Wiley, New York (1995). 

• G. Heerkens, Project Management, McGraw-Hill, New York (2001). 
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Chapter 2 

History of Project Management 1 



Could the Great Wall of China, the pyramids, or Stonehenge (Figure 2.1) have been built without project 
management? It is possible to say that the concept of project management has been around since the 
beginning of history. It has enabled leaders to plan bold and massive projects and manage funding, materials 
and labor within a designated time frame. 




Figure 2.1: Stonehenge was erected between 3,000 BC and 1,600 BC by no less than three different 
cultures and its orientation on the rising and setting sun has always been one of its remarkable features. 



In late 19 th century, in the United States, large-scale government projects were the impetus for making 
important decisions that became the basis for project management methodology such as the transcontinental 
railroad, which began construction in the 1860s. Suddenly, business leaders found themselves faced with the 
daunting task of organizing the manual labor of thousands of workers and the processing and assembly of 
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unprecedented quantities of raw material. 



Team Work 




Figure 2.2: This is what can happen without effective project management. 



Near the turn of the century, Frederick Taylor (Figure 2.3) began his detailed studies of work. He 
applied scientific reasoning to work by showing that labor can be analyzed and improved by focusing on its 
elementary parts that introduced the concept of working more efficiently, rather than working harder and 
longer. 




Figure 2.3: Frederick Taylor (1856-1915). 



Taylor's associate, Henry Gantt (Figure 2.4), studied in great detail the order of operations in work and 
is most famous for developing the Gantt Chart in the 1910s. A Gantt chart is a popular type of bar chart 
that illustrates a project schedule and have become a common technique for representing the phases and 
activities of a project work breakdown structure, so they can be understood by a wide audience (Figure 2.5). 
Although now considered a common charting technique, Gantt charts were considered quite revolutionary at 
the time they were introduced. Gantt charts were employed on major infrastructure projects including the 
Hoover Dam and the Interstate highway system and are still accepted today as an important tool in project. 
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Figure 2.4: Henry Gantt (1861 - 1919). 
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Figure 2.5: An example of a Gantt chart showing the relationship between a series of tasks. 



By the mid Twentieth century, projects were managed on an ad hoc basis using mostly Gantt Charts, and 
informal techniques and tools. During that time, the Manhattan project was initiated and its complexity 
was only possible because of project management methods. The Manhattan project was the codename given 
to the Allied effort to develop the first nuclear weapons during World War II. It involved over thirty different 
project sites in the US and Canada, and thousands of personnel from US, Canada and UK. Born out of a 
small research program that began in 1939, the Manhattan Project would eventually employ 130,000 people 
and cost a total of nearly 2 billion USD and result in the creation of multiple production and research sites 
operated in secret. The project succeeded in developing and detonating three nuclear weapons in 1945. 

The 1950s marked the beginning of the modern Project Management era. Two mathematical project- 
scheduling models were developed: 



1. The Program Evaluation and Review Technique or PERT, developed by Booz- Allen & Hamilton as part 
of the United States Navy's (in conjunction with the Lockheed Corporation) Polaris missile submarine 
program. Pert is basically a method for analyzing the tasks involved for completing a given project, 
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especially the time needed to complete each task, and identifying the minimum time needed to complete 
the total project (Figure 2.6). 
2. The Critical Path Method (CPM) developed in a joint venture by both DuPont Corporation and 
Remington Rand Corporation for managing plant maintenance projects. The critical path determines 
the float, or schedule flexibility, for each activity by calculating the earliest start date, earliest finish 
date, latest start date, and latest finish date for each activity. The critical path is generally the longest 
full path on the project. Any activity with a float time that equals zero is considered a critical path 
task. CPM can help you figure out how long your complex project will take to complete and which 
activities are critical; meaning they have to be done on time or else the whole project will take longer. 
These mathematical techniques quickly spread into many private enterprises. 



t=3mo 




Figure 2.6: An example of a PERT network chart for a seven-month project with five milestones. 



Project management in its present form began to take root a few decades ago. In the early 1960s, industrial 
and business organizations began to understand the benefits of organizing work around projects. They 
understood the critical need to communicate and integrate work across multiple departments and professions. 

The Project Management Institute (PMI) was founded in 1969 by five volunteers. Their initial goal was 
to establish an organization where members could share their experiences in project management and to 
discuss issues. Today, PMI is a non-profit project management professional association and the most widely 
recognized organization in terms of promoting project management best practices. PMI was formed to serve 
the interests of the project management industry. The premise of PMI is that the tools and techniques 
of project management are common even among the widespread application of projects from the software 
to the construction industry. PMI first began offering the PMP certification exam in 1984. Although it 
took a while for people to take notice, now more than 260,000 individuals around the world hold the PMP 
designation. 

To help keep project management terms and concepts clear and consistent, PMI introduced the Project 
Management Body of Knowledge (PMBOK) Guide in 1987. They updated it in 1996, 2000, 2004, and most 
recently in 2009 as the fourth edition. At present, there are more than 1 million copies of the PMBOK Guide 
in circulation. The highly regarded Institute of Electrical and Electronics Engineers (IEEE) have adopted 
it as their project management standard. 

In 1999 PMI was accredited as an American National Standards Institute (ANSI) standards developer and 
also has the distinction of being the first organization to have its certification program attain International 
Organization for Standardization (ISO) 9001 recognition. In 2008, the organization reported more than 
260,000 members in over 171 countries. PMI also has offices in Washington, D.C., and Beijing, China, as 
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well as Regional Service Centers in Singapore, Brussels (Belgium) and New Delhi (India). Recently, an office 
was opened in Mumbai (India). 



Chapter 3 

What is a Project? 1 



The starting point in discussing how projects should be properly managed is to first understand what a 
project is and just as importantly what it is not. 

People have been undertaking projects since the earliest days of organized human activity. The hunting 
parties of our prehistoric ancestors were projects for example; they were temporary undertakings directed 
at the goal of obtaining meat for the community. Large complex projects have also been with us for a long 
time. The pyramids and the Great Wall of China, were in their day of roughly the same dimensions as the 
Apollo Project to send man to the moon. We use the term project frequently in our daily conversations. A 
husband, for example may tell his wife, "My main project for this weekend is to straighten out the garage." 
Going hunting, building pyramids, and fixing faucets all share certain features that make them projects. 

A project has distinctive attributes, which distinguish it from ongoing work or business operations. 
Projects are temporary in nature. They are not an everyday business process and have definitive start dates 
and end dates. This characteristic is important because a large part of the project effort is dedicated to 
ensuring that the project is completed at the appointed time. To do this, schedules are created showing 
when tasks should begin and end. Projects can last minutes, hours, days, weeks, months or years. 

Projects exist to bring about a product or service that hasn't existed before. In this sense, a project is 
unique. Unique means that this is new, this has never been done before. Maybe it's been done in a very 
similar fashion before but never exactly in this way. For example, Ford Motor Company is in the business 
of designing and assembling cars. Each model that Ford designs and produces can be considered a project. 
The models differ from each other in their features and are marketed to people with various needs. An SUV 
serves a different purpose and clientele than a luxury model. The design and marketing of these two models 
are unique projects. However the actual assembly of the cars is considered an operation, i.e., a repetitive 
process that is followed for most makes and models. 

In contrast with projects, operations are ongoing and repetitive. They involve work that is continuous 
without an ending date and you often repeat the same processes and produce the same results. The purpose 
of operations is to keep the organization functioning while the purpose of a project is to meet its goals and 
to conclude. Therefore, operations are ongoing while projects are unique and temporary. 

The project is completed when its goals and objectives are accomplished. It is these goals that drive the 
project and all the planning and implementation efforts are undertaken to achieve them. Sometimes projects 
end when it's determined that the goals and objectives cannot be accomplished or when the product or 
service of the project is no longer needed and the project is cancelled. 

3.1 A formal definition of a project 

There are many written definitions of a project, however, all of them contain the key elements described 
above. For those looking for a formal definition of a project the Project Management Body of Knowledge 
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(PMBOK) defines a project as a temporary endeavor undertaken to create a unique product, service or 
result. The temporary nature of projects indicates a definite beginning and end. The end is reached when 
the project's objectives have been achieved or when the project is terminated because its objectives will not 
or cannot be met, or when the need for the project no longer exists. 

3.2 Bibliography 

• J. Davidson Frame, Managing Projects in Organizations, Wiley, New York (1995). 



Chapter 4 

Project Characteristics 1 



When considering whether or not you have a project on your hands, there are some things to keep in mind. 
First, is it a project or ongoing operation? Next, if it is a project; who are the stakeholders? And third, 
what characteristics distinguish this endeavor as a project? 
A project has several characteristics: 

• Projects are unique. 

• Projects are temporary in nature and have a definite beginning and ending date. 

• Projects are completed when the project goals are achieved or it's determined the project is no longer 
viable. 

• A successful project is one that meets or exceeds the expectations of your stakeholders. 

Consider the following scenario: The VP of marketing approaches you with a fabulous idea. (Obviously 
it must be "fabulous" because he thought of it.) He wants to set up kiosks in local grocery stores as mini 
offices. These offices will offer customers the ability to sign up for car and home insurance services as well 
as make their bill payments. He believes that the exposure in grocery stores will increase awareness of the 
company's offerings. He told you that senior management has already cleared the project and he'll dedicate 
as many resources to this as he can. He wants the new kiosks in place in 12 selected stores in a major city 
by the end of the year. Finally, he has assigned you to head up this project. 

Your first question should be "Is it a project?" This may seem elementary, but confusing projects with 
ongoing operations happens often. Projects are temporary in nature, have definite start and end dates, result 
in the creation of a unique product or service, and are completed when their goals and objectives have been 
met and signed off by the stakeholders. 

Using these criteria, let's examine the assignment from the VP of marketing to determine if it is a project: 

Is it unique? Yes, because the kiosks don't exist in the local grocery stores. This is a new way of 
offering the company's services to its customer base. While the service the company is offering isn't new, 
the way it is presenting its services is. 

Does the product have a limited timeframe? Yes, the start date of this project is today, and the 
end date is the end of next year. It is a temporary endeavor. 

Is there a way to determine when the project is completed? Yes, the kiosks will be installed and 
the services will be offered from them. Once all the kiosks are intact and operating, the project will come 
to a close. 

Is there a way to determine stakeholder satisfaction? Yes, the expectations of the stakeholders 
will be documented in the form of requirements during the planning processes. These requirements will be 
compared to the finished product to determine if it meets the expectations of the stakeholder. 

If the answer is yes to all these questions, then "Houston, we have a project". 



1 This content is available online at <http://cnx.Org/content/m31437/l.l/>. 
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Chapter 5 

Project Stakeholders 1 



A project is successful when it achieves its objectives and meets or exceeds the expectations of the stake- 
holders. But who are the stakeholders? Stakeholders are individuals who either care about or have a vested 
interest in your project. They are the people who are actively involved with the work of the project or have 
something to either gain or lose as a result of the project. When you manage a project to add lanes to a 
highway, motorists are stakeholders who are positively affected. However, you negatively affect residents who 
live near the highway during your project (with construction noise) and after your project with far reaching 
implications (increased traffic noise and pollution). 

note: Key stakeholders can make or break the success of a project. Even if all the deliverables are 
met and the objectives are satisfied, if your key stakeholders aren't happy, nobody's happy. 

The project sponsor, generally an executive in the organization with the authority to assign resources and 
enforce decisions regarding the project, is a stakeholder. The customer, subcontractors, suppliers and some- 
times even the Government are stakeholders. The project manager, project team members and the managers 
from other departments in the organization are stakeholders as well. It's important to identify all the stake- 
holders in your project upfront. If you leave out an important stakeholder or their department's function 
and don't discover the error until well into the project, it could be a project killer. 

Figure 5.1 shows a sample of the project environment featuring the different kinds of stakeholders involved 
on a typical project. A study of this diagram confronts us with a couple of interesting facts. 

• First, the number of stakeholders that project managers must deal with assures that they will have 
a complex job guiding their project through the lifecycle. Problems with any of these members can 
derail the project. 

• The diagram also shows that project managers have to deal with people external to the organization 
as well as the internal environment, certainly more complex than what a manager in an internal 
environment faces. For example, suppliers who are late in delivering crucial parts may blow the project 
schedule. To compound the problem, project managers generally have little or no direct control over 
any of these individuals. 



1 This content is available online at <http://cnx.Org/content/m31209/l.2/>. 



17 



18 



CHAPTER 5. PROJECT STAKEHOLDERS 



Government 



Contractors & 
Subcontractors 



Top Management 

Project Team Members 

Your Manager 

Peers 

Resource Manager 

Internal Customers 



External 
Customers 



Suppliers 



Figure 5.1: Project stakeholders. 



Let's take a look at these stakeholders and their relationships to the project manager. 

5.1 Top management 

Top management may include the president of the company, vice presidents, directors, division managers, 
the corporate operating committee, and others. These people direct the strategy and development of the 
organization. 

On the plus side, you more likely to have top management support, which means it will be easier to 
recruit the best staff to carry out the project, and to acquire needed material and resources; also visibility 
can enhance PM's professional standing in the company. 

On the minus side, failure can be quite dramatic and visible to all, and if the project is large and expensive 
(most are) the cost of failure will be more substantial than for a smaller less visible project. 

Some suggestions in dealing with top management are: 

• Develop in-depth plans and major milestones that must be approved by top management during the 
design phase of the project. 

• Ask top management associated with your project for their information reporting needs and frequency. 

• Develop a status reporting methodology to be distributed on a scheduled basis. 

• Keep them informed of project risks and potential impacts at all times. 



5.2 The project team 

Your project team available to project managers on their project or borrowed rather than assigned to the 
project on a full time basis. As project manager you need to provide leadership, direction and above all, 
the support to team members as they go about accomplishing their tasks. Working closely with the team to 
solve problems can help you learn from the team and build rapport. Showing your support for the project 
team and for each member will help you get their support and cooperation. 
Some difficulties in dealing with project team members include: 
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• Since project team members are borrowed and they don't report to you, their priorities may be else- 
where. 

• They may be juggling many projects as well as their full time job and have difficulty meeting any 
deadline. 

• Personality conflicts may arise. These may be cause by differences in social style or values or they may 
be the result of some bad experience when people worked together in the past. 

• You may find out about missed deadlines when it is too late to recover. 

Managing project team members requires interpersonal skills. Here are some suggestions that can help: 

• Involve team members in project planning. 

• Arrange to meet privately and informally with each team member at several points in the project, 
perhaps for lunch or coffee. 

• Be available to hear team members concerns at any time. 

• Encourage team members to pitch in and help others when needed. 

• Complete a project performance review for team members. 

5.3 Your manager 

Typically the boss decides what our assignment is and who can work with us on our projects. Keeping your 
manager informed will help ensure that you get the necessary resources to complete your project. 

• If things go wrong on a project, it is nice to have an understanding and supportive boss to go to bat 
for us if necessary. By supporting your manager, you will find your manager will support you more 
often. 

• Find out exactly how your performance will be measured. 

• When unclear about directions, ask for clarification. 

• Develop a reporting schedule that is acceptable to your boss. 

• Communicate frequently. 

5.4 Peers 

Peers are people on the project team who are at the same level in the organization as you. These people 
will, in fact, also have a vested interest in the product. However, they will have neither the leadership 
responsibilities nor the accountability for the success or failure of the project that you have. 
Your relationship with peers can be impeded by: 

• Inadequate control over peers. 

• Political maneuvering or sabotage. 

• Personality conflict or technical conflict. 

• Envy because your peer may have wanted to lead the project. 

• Conflicting instructions from your manager and your peer's manager. 

Peer support is essential. Because most of us serve our self-interest first, use some investigating, selling, 
influencing and politicking skills here. To ensure you have cooperation and support from your peers: 

• Get the support of your project sponsor or top management to empower you as the project manager 
with as much authority as possible. It's important that the sponsor makes it clear to the other team 
members that their cooperation on project activities is expected. 

• Confront your peer if you notice a behavior that seems dysfunctional, such as bad-mouthing the project. 

• Be explicit in asking for full support from your peers. 

• Arrange for frequent review meetings. 

• Establish goals and standards of performance for all team members. 
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5.5 Resource managers 

Because project managers are in the position of borrowing resources, other managers control their resources. 
So their relationships with people are especially important. If their relationship is good, they may be able 
to consistently acquire the best staff and the best equipment for their projects. If relations aren't so good, 
they may find themselves not able to get good people or equipment needed on the project. 

5.6 Internal customer 

Internal customers are individuals within the organization who have projects that meet the needs of internal 
demands. The customer holds the power to accept or reject your work. Early in the relationship, the project 
manager will need to negotiate, clarify, and document project specifications and deliverables. After the 
project begins, the project manager must stay tuned in to the customer's concerns and issues and keep the 
customer informed. 

Common stumbling blocks when dealing with customers include: 

• A lack of clarity about precisely what is wanted by the customer. 

• A lack of documentation for what is wanted. 

• A lack of knowledge of the customer's organization and operating characteristics. 

• Unrealistic deadlines, budgets, or specifications. 

• Hesitancy to sign off on the project or accept responsibility for decisions. 

• Changes in project scope. 

To meet the needs of the customer, client or owner, be sure to do the following: 

• Learn the client's organization's buzzwords, culture, and business. 

• Clarify all project requirements and specifications in a written agreement. 

• Specify a change procedure. 

• Establish the project manager as the focal point of communications in the project organization. 

5.7 External customer 

External customers are the customers when projects could be marketed to outside customers. In the case of 
Ford Motor Company for example, the external customers would be the buyers of the automobiles. 

5.8 Government 

Project managers working in certain heavily regulated environment (e.g., pharmaceutical, banking industries, 
etc.) will have to deal with government regulators and departments. These can include all or some levels 
from city, through county, state, and federal, to international. 

5.9 Contractors, subcontractors, and suppliers 

There are times when organizations don't have the expertise in house or available resources and work is farmed 
out to contractors or subcontractors. This can be a construction management firm, network consultants, 
electricians, carpenters, architects, and in general anyone who is not an employee. Managing contractors or 
suppliers requires many of the skills needed to manage full-time project team members. 
Any number of problems can arise with contractors or subcontractors: 

• Quality of the work. 



21 

• Cost overruns. 

• Schedule slippage. 

Many projects heavily depend on goods provided by outside suppliers. This is true for example of construction 
projects where lumber, nails, brick and mortar come from outside suppliers. 

• If the supplied goods are delivered late or in short supply or of poor quality or if the price is greater 
than originally quoted, the project may suffer. 

Depending on the project, managing relationships can consume more than half of the project manager's time. 
It is not purely intuitive; it involves a sophisticated skill set that includes managing conflicts, negotiating, 
and other interpersonal skills. 
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Chapter 6 

The Politics of Projects 1 



Many times, project stakeholders have conflicting interests. It's the project manager's responsibility to 
understand these conflicts and try to resolve them. It's also the project manger's responsibility to manage 
stakeholder expectations. Be certain to identify and meet with all key stakeholders early in the project to 
understand all their needs and constraints. 

Project managers are somewhat like politicians. Typically, they are not inherently powerful, or capable 
of imposing their will directly to co-workers, subcontractors and suppliers. Like politicians, if they are to get 
their way, they have to exercise influence effectively over others. On projects, project managers have direct 
control over very few things; therefore their ability to influence others- to be a good politician- may be very 
important 

Here are a few steps a good project politician should follow. However, a good rule is that when in doubt, 
stakeholder conflicts should always be resolved in favor of the customer. 

6.1 Assess the environment 

Identify all the relevant stakeholders. Because each of these stakeholders could derail the project we need to 
consider their particular interest in the project. 



• 



Once all relevant stakeholders are identified, we try to determine where the power lies. 



• In the vast cast of characters we confront, who counts most? 



• 



Whose actions will have the greatest impact? 



6.2 Identify goals 

After determining whom the stakeholders are, we should identify their goals. 



What is it that drives them? 

What is each after? 

We should also be aware of hidden agendas of goals that are not openly articulated. 

We need to pay special attention to the goals of the stakeholders who hold the power. 



6.3 Define the problem 

• The facts that constitute the problem should be isolated and closely examined. 



• 



The question should be raised "What is the real situation?" over and over. 



1 This content is available online at <http://cnx.Org/content/m31439/l.2/>. 
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Chapter 7 

What is Project Management? 1 



You've determined that you have a project. What now? The notes you scribbled down on the back of the 
napkin at lunch are a start, but not exactly good project management practice. Too often, organizations 
follow Nike's advice when it comes to managing projects when they "just do it." An assignment is made 
and the project team members jump directly into the development of the product or service requested. In 
the end the delivered product doesn't meet the expectations of the customer. Unfortunately, many projects 
follow this poorly constructed path and that is a primary contributor to why a large percentage of projects 
don't meet their original objectives defined by performance, schedule, and budget. 

In the United States, more than $250 billion dollars is spent each year on IT application development 
in approximately 175,000 projects. The Standish Group (a Boston-based leader in project and value perfor- 
mance research) just released the summary version of their 2009 CHAOS Report that tracks project failure 
rates across a broad range of companies and industries (Figure 7.1). 



Challenged = late, 
overbudget, and/or 
withless than the required 
features and functions 




Successful = delivered on time, 
on budget, with required 
features and functions 



Failed = cancelled prior 
to completion or 
delivered and never used 



Figure 7.1: Summary of 2009 Standish Group CHAOS report. 



Jim Johnson, chairman of the Standish Group has stated that "this year's results show a marked decrease 
in project success rates, with 32% of all projects succeeding which are delivered on time, on budget, with 
required features and functions, 44% were challenged which are late, over budget, and/or with less than 
the required features and functions and 24% failed which are cancelled prior to completion or delivered and 



1 This content is available online at <http://cnx.org/content/m31508/!. 4/>. 
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never used." 

When are companies going to stop wasting billions of dollars on failed projects? The vast majority of this 
waste is completely avoidable; simply get the right business needs (requirements) understood early in the 
process and ensure that project management techniques are applied and followed and the project activities 
are monitored. 

Applying good project management discipline is the way to help reduce the risks. But keep in mind, 
having good project management skills does not mean you have no problems, it does not mean that risks go 
away, or that there won't be any surprises. The value of good project management is that you have standard 
processes in place to deal with all contingencies. 

Project Management is the application of knowledge, skills, tools, and techniques applied to project 
activities in order to meet the project requirements. Project management is a process that includes planning, 
putting the project plan into action, and measuring progress and performance. 

Managing a project includes identifying your project's requirements; writing down what everyone needs 
from the project. What are the objectives for your project? When everyone understands the goal, it's much 
easier to keep them all on the right path. Make sure you set goals that everyone agrees on to avoid team 
conflicts later on. Understanding and addressing the needs of everyone affected by the project means the 
end result of your project is far more likely to satisfy your stakeholders, and last but not least, as project 
manager you will also be balancing the many competing project constraints. 

On any project, you will have a number of competing project constraints that are competing for your 
attention. They are cost, scope, quality, risk, resources and time. 

• Cost is budget approved for the project including all necessary expenses needed to deliver the project. 
Within organizations, project managers have to balance between not running out of money and not 
under spending because many projects receive funds or grants that have contract clauses with an "use 
it or lose it" approach to project funds. Poorly executed budget plans can result in a last minute rush 
to spend the allocated funds. For virtually all projects, cost is ultimately a limiting constraint; few 
projects can go over budget without eventually requiring a corrective action. 

• Scope is what the project is trying to achieve, it entails all the work involved in delivering the projects 
outcomes and the processes used to produce them. It is the reason and the purpose of the project. 

• Quality is the standards and criteria to which the project's products must be delivered for them to 
perform effectively. First, the product must perform to provide the functionality expected, and to solve 
the problem, and deliver the benefit and value expected of it. It must also meet other performance 
requirements, or service levels, such as availability, reliability and maintainability, and have acceptable 
finish and polish. Quality on a project is controlled through quality assurance (QA) that is the process 
of evaluating overall project's performance on a regular basis to provide confidence that the project 
will satisfy the relevant quality standards. 

• Risk is defined by potential external events that will have a negative impact on your project if they 
occur. Risk refers to the combination of the probability the event will occur and the impact on the 
project if the event occurs. If the combination of the probability of the occurrence and the impact to 
the project is too high, you should identify the potential event as a risk and put a proactive plan in 
place to manage the risk. 

• Resources are required to carry out the project tasks. They can be people, equipment, facilities, 
funding, or anything else capable of definition (usually other than labor) required for the completion 
of a project activity. 

• Time is defined as the time to complete the project. Time is often the most frequent project oversight 
in developing projects. This is reflected in missed deadlines and incomplete deliverables. Proper control 
of the schedule requires the careful identification of tasks to be performed, an accurate estimation of 
their durations, the sequence in which they are going to be done, and how people and other resources 
are allocated. 

You may have heard of the term "Triple Constraint" which traditionally only consisted of Time, Cost & 
Scope. These are the primary competing project constraints that you have to be aware of most. The triple 
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constraint is illustrated in the form of a triangle to visualize the project work and to see the relationship 
between the scope/quality, schedule/time, and cost/resource (Figure 7.2). 




Scope/Quality 



Figure 7.2: A schematic of the triple constraint triangle. 



In this triangle, each side represents one of the constraints (or related constraints) wherein any changes 
to any one side cause a change in the other sides. The best projects have a perfectly balanced triangle. 
Maintaining this balance is difficult because projects are prone to change. For example, if scope increases, 
cost and time may increase disproportionately. Alternatively, if the amount of money you have for your 
project decreases, you may be able to do as much, but your time may increase. 

Your project may have additional constraints that you are facing, and as the project manager you have to 
balance the needs of these constraints against the needs of the stakeholders and against your project goals. 
For instance, if your sponsor wants to add functionality to the original scope you will very likely need more 
money to finish the project or if they cut the budget you have to reduce the quality of your scope and if 
you don't get the appropriate resources to work on your project tasks you will have to extend your schedule 
because the resources you have take much longer to finish the work. 

You get the idea; they are all dependent on each other. Think of all of these constraints as the classic 
carnival game of Whac-a-mole (Figure 7.3). Each time you try to push one mole back in the hole, another 
one pops out. The best advice is to rely on your project team to keep these moles in place! 
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Figure 7.3: Go to www.dorneypark.com/public/online_fun/mole.cfm to play Whac-a-mole. 



Here is an example of a project that cut quality because the project costs were fixed. The P-36 oil 
platform (Figure 7.4) was the largest floating production platform in the world capable of processing 180,000 
barrels of oil per day and 7.2 million cubic meters of gas per day. Located in the Roncador Field, Campos 
Basin, Brazil the P-36 was operated by Petrobras. 




Figure 7.4: The Petrobras P-36 oil platform. 



In March 2001, the P-36 was producing around 84,000 barrels of oil and 1.3 million cubic meters of gas 
per day when it became destabilized by two explosions and subsequently sank in 3900 feet of water with 
1650 short tons of crude oil remaining on board, killing 11 people. 

The sinking is attributed to a complete failure in quality assurance and pressure for increased production 
led to corners being cut on safety procedures. It is listed as one of the most expensive accidents with a price 
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tag of $515,000,000. 

The following quote is from a Petrobras executive, citing the benefits of cutting quality assurance and 
inspection costs on the project, while the accompanying pictures are the result of this proud achievement in 
project management by Petrobras. 




Figure 7.5: "Petrobras has established new global benchmarks for the generation of exceptional share- 
holder wealth through an aggressive and innovative program of cost cutting on its P36 production facility." 




Figure 7.6: "Conventional constraints have been successfully challenged and replaced with new 
paradigms appropriate to the globalized corporate market place." 
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Figure 7.7: "Through an integrated network of facilitated workshops, the project successfully rejected 
the established constricting and negative influences of prescriptive engineering, onerous quality require- 
ments, and outdated concepts of inspection and client control." 




Figure 7.8: "Elimination of these unnecessary straitjackets has empowered the project's suppliers and 
contractors to propose highly economical solutions, with the win-win bonus of enhanced profitability 
margins for themselves." 
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Figure 7.9: "The P36 platform shows the shape of things to come in the unregulated global market 
economy of the 21 st century." 



The dynamic trade-offs between the project constraint values has been humorously but accurately de- 
scribed in Figure 7.10. 



"We can do GOOD, QUICK and CHEAP work. 

You can have any two but not all three. 

1. GOOD QUICK work won't be CHEAP. 

2. GOOD CHEAP work won't be QUICK. 

3. QUICK CHEAP work won't be GOOD." 



Figure 7.10: A sign seen at an automotive repair shop. 



7.1 Bibliography 

• CHAOS 2009 Summary and EPPM Study, The Standish Group, Boston, MA (2009). 
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Chapter 8 

Project Management Areas of Expertise 1 



In order for you as the project manager to manage the competing project constraints and to manage the 
project as a whole, there are some areas of expertise that you should bring onto the project team (Figure 8.1). 
They are the application area of knowledge; standards and regulations in your industry, understanding the 
project environment, and you must have general management knowledge and interpersonal skills. It should 
be noted that the industry expertise is not in a certain field but the expertise in order to run the project. 
So while knowledge of the type of industry is important you will have a project team supporting you in this 
endeavor. For example, if you are managing a project that is building an oil platform, you would not be 
expected to have a detailed understanding of the engineering since your team will have mechanical and civil 
engineers who will provide the appropriate expertise, however, it would definitely help if you understand this 
type of work. 

Let's take a look at each of these areas in more detail. 



Areas of Expertise 



Application knowledge, standards & regulations 



Understanding the project environment 



Management knowledge & skills 
Interpersonal skills 



Figure 8.1: Areas of expertise that a project manager should bring to the project team. 



8.1 Application knowledge; standards & regulations 

By standards, we mean guidelines or preferred approaches that are not necessarily mandatory. In contrast, 
when referring to regulations we mean mandatory rules that must be followed such as Government imposed 
requirements through laws. It should go without saying that as a professional, you're required to follow all 
applicable laws and rules that apply to your industry, organization, or project. Every industry has standards 



1 This content is available online at <http://cnx.Org/content/m31888/l.2/>. 



33 



34 



CHAPTER 8. PROJECT MANAGEMENT AREAS OF EXPERTISE 



and regulations. Knowing which ones effect your project before you begin work will not only help the project 
to unfold smoothly, but will also allow for effective risk analysis. 

Some projects require specific skills in certain application areas. Application areas are made up of cat- 
egories of projects that have common elements. They can be defined by: industry group (pharmaceutical, 
financial, etc), by department (accounting, marketing, legal, etc), by technical (software development, en- 
gineering, etc), or management (procurement, research, & development, etc) specialties. These application 
areas are usually concerned with disciplines, regulations and the specific needs of the project, the customer, 
or the industry. For example, most government agencies have specific procurement rules that apply to their 
projects that wouldn't be applicable in the construction industry. The pharmaceutical industry is interested 
in regulations set forth by the Food and Drug Administration, whereas the automotive industry has little 
or no concern for either of these types of regulations. You need to stay up-to-date regarding your industry 
so that you can apply your knowledge effectively. Today's fast paced advances can leave you behind fairly 
quickly if you don't stay abreast on current trends. 

Having some level of experience in the application area you're working in will give you an advantage when 
it comes to project management. While you can call in experts who have the application area knowledge, it 
doesn't hurt for you to understand the specific aspects of the application areas of your project. 

8.2 Understanding the project environment 

There are many factors that need to be understood within your project environment (Figure 8.2). At 
one level you need to understand your project environment by thinking in terms of the cultural and the 
social environment. In this region we think of people, demographics and education. The international and 
political environment is where you need to understand about different countries cultural influences. Then 
we move on to the physical environment; here we think about time zones, think about different countries 
and how differently your project will be executed whether it is just in your country or whether you have an 
international project team that is distributed throughout the world in five different countries. 



Project Environment 


Cultural 


Social 


International 


Political 


Physical 



Figure 8.2: The important factors to consider within the project environment. 



Of all the factors the physical ones are the easiest to understand, and it is the cultural and international 
factors that are often misunderstood or ignored. How we deal with clients, customers, or project members 
from other countries can be critical to the success of the project. For example, the culture of the United 
States values accomplishments and individualism. Americans tend to be informal and call each other by first 
names, even if having just met. Europeans tend to be more formal, using surnames instead of first names in 
a business setting, even if they know each other well. In addition, their communication style is more formal 
than in the US, and while they tend to value individualism, they also value history, hierarchy, and loyalty. 
The Japanese, on the other hand, tend to communicate indirectly and consider themselves part of a group, 
not as individuals. The Japanese value hard work and success, as most of us do. 
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How a product is received can be very dependent on the international cultural differences. For example, 
in the nineties, when many large American and European telecommunications companies were cultivating 
new markets in Asia, their customer's cultural differences often produced unexpected situations. Western 
companies planned their telephone systems to work the same way in Asia as they did in Europe and America. 
But the protocol of conversation was different. Call- waiting, a popular feature in the West, is considered 
impolite in some parts of Asia. This cultural blunder could have been avoided had the team captured the 
project environment requirements and involved the customer. 

It is often the simplest things that can cause trouble since unsurprisingly in different countries people do 
things differently. One of the most notorious examples of this is also one of the most simple: date formats. 
What day and month is 2/8/2009? Of course it depends where you come from; in North America it is 
February 8 th while in Europe (and much of the rest of the world) it is 2 nd August. Clearly, when schedules 
and deadlines are being defined it is important that everyone is clear on the format used. 

The diversity of practices and cultures and its impact on products in general and on software in particular, 
goes well beyond the date issue. You may be managing a project to create a new website for a company 
that sells products worldwide. There are language and presentation style issues to take into consideration; 
converting the site into different languages isn't enough. It is obvious to ensure that the translation is correct, 
however, the presentation layer will have its own set of requirements for different cultures. The left side of 
a web site may be the first focus of attention for an American; the right side would be the initial focus for 
anyone from the Middle East, as both Arabic and Hebrew are written from right to left. Colors also have 
different meanings in different cultures. White, which is a sign of purity in America (e.g., a bride's wedding 
dress), and thus would be a favored background color in North America, signifies death in Japan (e.g., a 
burial shroud). Table 8.1 summarizes different meanings of common colors. 



Color 


United 
States 


China 


Japan 


Egypt 


France 


Red 


Danger, stop 


Happiness 


Anger, danger 


Death 


Aristocracy 


Blue 


Sadness, 
melancholy 


Heavens, 
clouds 


Villainy 


Virtue, faith, 
truth 


Freedom, 
peace 


Green 


Novice, ap- 
prentice 


Ming dynasty, 
heavens 


Future, youth, 
energy 


Fertility, 
strength 


Criminality 


Yellow 


Cowardice 


Birth, wealth 


Grace, nobility 


Happiness, 
prosperity 


Temporary 


White 


Purity 


Death, purity 


Death 


Joy 


Neutrality 



Table 8.1: The meaning of colors in various cultures. Adapted from P. Russo and S. Boor, How Fluent is 

Your Interface? Designing for International Users, Proceedings of the INTERACT '93 and CHI '93, 

Association for Computing Machinery, Inc. (1993). 

Project managers in multicultural projects must appreciate the culture dimensions and try to learn 
relevant customs, courtesies, and business protocols before taking responsibility for managing an international 
project. A project manager must take into consideration these various cultural influences and how they may 
affect the project's completion, schedule, scope and cost. 

8.3 Management knowledge & skills 

As the project manager you have to rely on your project management knowledge and your general manage- 
ment skills. In this area we are thinking of items like your ability to plan the project, to execute the project 
properly and of course to control the project and bring it to a successful conclusion with the ability to guide 
the project team while achieving project objectives and balancing the project constraints. 
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There is more to project management than just getting the work done. Inherent to the process of project 
management are the general management skills that allow the project manager to complete the project with 
some level of efficiency and control. In some respects, managing a project is similar to running a business: 
there are risk and rewards, finance and accounting activities, human resource issues, time management, 
stress management, and a purpose for the project to exist. General management skills are needed in just 
about every project. 

8.4 Interpersonal skills 

Last but not least you also have to bring the ability onto the project to manage personal relationships as well 
as dealing with issues as they arise. Here were talking about your interpersonal skills as shown in Figure 8.3. 



Interpersonal Skills 


Communication 


Influence 


Leadership 


Motivation 


Negotiation 


Problem solving 



Figure 8.3: Interpersonal skills required of a project manager. 



8.4.1 Communication 

Project managers spend 90% of their time communicating. Therefore they must be good communicators, 
promoting clear unambiguous exchange of information. As a project manager, it is your job to keep a number 
of people well informed. It is essential that your project staff know what is expected of them: what they 
have to do, when they have to do it, and what budget and time constraints and quality specification they are 
working towards. If project staff does not know what their tasks are, or how to accomplish them, then the 
entire project will grind to a halt. If you do not know what the project staff is (or often is not) doing then 
you will be unable to monitor project progress. Finally, if you are uncertain of what the customer expects 
of you, then the project will not even get off the ground. Project communication can thus be summed up as 
who needs what information and when. 

All projects require sound communication plans, but not all projects will have the same types of commu- 
nication or the same methods for distributing the information. For example, will information be distributed 
via mail or e-mail, is there a shared web site, or are face-to-face meetings required? The communication 
management plan documents how the communication needs of the stakeholders will be met, including the 
types of information that will be communicated, who will communicate it, who receives the communication, 
the methods used to communicate, the timing and frequency, the method for updating the plan as the project 
progresses, escalation process, and a glossary of common terms. 



8.4.2 Influence 

Project management is about getting things done. Every organization is different in its policies, modes of 
operations and underlying culture. There are political alliances, differing motivations, conflicting interest, 
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and power struggles within every organization. A project manager must understand all of the unspoken 
influences at work within an organization. 

8.4.3 Leadership 

Leadership is the ability to motivate and inspire individuals to work towards expected results. Leaders 
inspire vision and rally people around common goals. A good project manager can motivate and inspire the 
project team to see the vision and value of the project. The project manager as a leader can inspire the 
project team to find a solution to overcome the perceived obstacles to get the work done. 

8.4.4 Motivation 

Motivation helps people work more efficiently and produce better results. Motivation is a constant process 
that the project manager must have to help the team move towards completion with passion and a profound 
reason to complete the work. Motivating the team is accomplished by using a variety of team building 
techniques and exercises. Team building is simply getting a diverse group of people to work together in 
the most efficient and effective manner possible. This may involve management events as well as individual 
actions designed to improve team performance. 

Recognition and rewards are an important part of team motivations. They are formal ways of recognizing 
and promoting desirable behavior and are most effective when carried out by the management team and 
the project manager. Consider individual preferences and cultural differences when using rewards and 
recognition. Some people don't like to be recognized in front of a group; others thrive on it. 

8.4.5 Negotiation 

Project managers must negotiate for the good of the project. In any project, the project manager, the 
project sponsor, and the project team will have to negotiate with stakeholders, vendors, and customers to 
reach a level of agreement acceptable to all parties involved in the negotiation process. 

8.4.6 Problem solving 

Problem solving is the ability to understand the heart of a problem, look for a viable solution, and then 
make a decision to implement that solution. The premise for problem solving is problem definition. Problem 
definition is the ability to understand the cause and effect of the problem; this centers on root cause analysis. 
If a project manager treats only the symptoms of a problem rather than its cause, the symptoms will 
perpetuate and continue through the project life. Even worse treating a symptom may result in a greater 
problem. For example, increasing the ampere rating of a fuse in your car because the old one keeps blowing 
does not solve the problem of an electrical short that could result in a fire. Root cause analysis looks beyond 
the immediate symptoms to the cause of the symptoms, which then affords opportunities for solutions. Once 
the root of a problem has been identified, a decision must be made to effectively address the problem. 

Solutions can be presented from vendors, the project team, the project manager or various stakeholders. 
A viable solution focuses on more than just the problem; it looks at the cause and effect of the solution itself. 
In addition, a timely decision is needed or the window of opportunity may pass and then a new decision will 
be needed to address the problem. As in most cases, the worst thing you can do is nothing. 

All of these interpersonal skills will be utilized in all areas of project management. Start practicing now 
because its guaranteed that you'll need these skills on your next project. 
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Chapter 9 

The Project Life Cycle' 



The project manager and project team have one shared goal: to carry out the work of the project for the 
purpose of meeting the project's objectives. Every project has beginnings, a middle period during which 
activities move the project toward completion, and an ending (either successful or unsuccessful). A standard 
project typically has the following four major phases (each with its own agenda of tasks and issues): initiation, 
planning, execution, and closure. Taken together, these phases represent the path a project takes from the 
beginning to its end and are generally referred to as the project life cycle (Figure 9.1). 




Figure 9.1: The four phase of the project life cycle. Adapted from J. Westland, The Project Manage- 
ment Lifecycle, Kogan Page Limited (2006). 



1 This content is available online at <http://cnx.Org/content/m31913/l.5/>. 
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9.1 Initiation phase 

During the first of these phases, the initiation phase, the project objective or need is identified; this can be a 
business problem or opportunity. An appropriate response to the need is documented in a business case with 
recommended solution options. A feasibility study is conducted to investigate whether each option addresses 
the project objective and a final recommended solution is determined. Issues of feasibility ("can we do the 
project?") and justification ("should we do the project?") are addressed. 

Once the recommended solution is approved, a project is initiated to deliver the approved solution and 
a project manager is appointed. The major deliverables and the participating work groups are identified 
and the project team begins to take shape. Approval is then sought by the project manager to move on the 
detailed planning phase. 

9.2 Planning phase 

The next phase, the planning phase, is where the project solution is further developed in as much detail as 
possible and you plan the steps necessary to meet the project's objective. In this step, the team identifies all 
of the work to be done. The project's tasks and resource requirements are identified, along with the strategy 
for producing them. This is also referred to as scope management. A project plan is created outlining the 
activities, tasks, dependencies and timeframes. The project manager coordinates the preparation of a project 
budget; by providing cost estimates for the labor, equipment and materials costs. The budget is used to 
monitor and control cost expenditures during project execution. 

Once the project team has identified the work, prepared the schedule and estimated the costs, the three 
fundamental components of the planning process are complete. This is an excellent time to identify and try 
to deal with anything that might pose a threat to the successful completion of the project. This is called 
risk management. In risk management, "high-threat" potential problems are identified along with the action 
that is to be taken on each high threat potential problem, either to reduce the probability that the problem 
will occur or to reduce the impact on the project if it does occur. This is also a good time to identify 
all project stakeholders, and to establish a communication plan describing the information needed and the 
delivery method to be used to keep the stakeholders informed. 

Finally, you will want to document a quality plan; providing quality targets, assurance, and control 
measures along with an acceptance plan; listing the criteria to be met to gain customer acceptance. At this 
point, the project would have been planned in detail and is ready to be executed. 

9.3 Execution phase 

During the third phase, the execution phase, the project plan is put into motion and performs the work of 
the project. It is important to maintain control and communicate as needed during execution. Progress is 
continuously monitored and appropriate adjustments are made and recorded as variances from the original 
plan. In any project a project manager will spend most of their time in this step. During project execution, 
people are carrying out the tasks and progress information is being reported through regular team meetings. 
The project manager uses this information to maintain control over the direction of the project by measuring 
the performance of the project activities comparing the results with the project plan and takes corrective 
action as needed. The first course of action should always be to bring the project back on course, i.e., to 
return it to the original plan. If that cannot happen, the team should record variations from the original 
plan and record and publish modifications to the plan. Throughout this step, project sponsors and other key 
stakeholders should be kept informed of project status according to the agreed upon frequency and format. 
The plan should be updated and published on a regular basis (Figure 9.2). 
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Figure 9.2: One year in a project - Day 19. 



Status reports should always emphasize the anticipated end point in terms of cost, schedule and quality 
of deliverables. Each project deliverable produced should be reviewed for quality and measured against the 
acceptance criteria. Once all of the deliverables have been produced and the customer has accepted the final 
solution, the project is ready for closure. 

9.4 Closure phase 

During the final closure, or closeout phase, the emphasis is on releasing the final deliverables to the cus- 
tomer, handing over project documentation to the business, terminating supplier contracts, releasing project 
resources and communicating the closure of the project to all stakeholders. The last remaining step is to 
conduct lessons learned studies; to examine what went well and what didn't. Through this type of analysis 
the wisdom of experience is transferred back to the project organization, which will help future project 
teams. 



9.5 Bibliography 

• J. Westland, The Project Management Lifecycle, Kogan Page Limited (2006). 
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Chapter 10 

Project Initiation 1 



The project initiation phase is the first phase within the project management life cycle, as it involves starting 
up a new project. Within the initiation phase, the business problem or opportunity is identified, a solution 
is defined, a project is formed, and a project team is appointed to build and deliver the solution to the 
customer. A business case is created to define the problem or opportunity in detail and identify a preferred 
solution for implementation. The business case includes: 

• A detailed description of the problem or opportunity 

• A list of the alternative solutions available 

• An analysis of the business benefits, costs, risks and issues 

• A description of the preferred solution 

• A summarized plan for implementation 

The project sponsor then approves the business case, and the required funding is allocated to proceed with 
a feasibility study. It is up to the project sponsor to determine if the project is worth undertaking and 
whether the project will be profitable to the organization. The completion and approval of the feasibility 
study triggers the beginning of the planning phase. The feasibility study may also show that the project is 
not worth pursuing and the project is terminated; thus the next phase never begins. 

All projects are created for a reason. Someone identifies a need and devises a project to address that 
need. How well the project ultimately addresses that need defines the project's success or failure. 

The success of your project depends on the clarity and accuracy of your business case and whether people 
believe they can achieve it. Whenever you consider past experience, your business case is more realistic; 
and whenever you involve people in the business case's development, you encourage their commitment to 
achieving it. 

Often the pressure to get results encourages people to go right into identifying possible solutions without 
fully understanding the need; what the project is trying to accomplish. This strategy can create a lot 
of immediate activity but it also creates significant chances for waste and mistakes if the wrong need is 
addressed. One of the best ways to gain approval for a project is to clearly identify the project's objectives 
and describe the need or problem for which the project will provide a solution. 

For most of us, being misunderstood is a common occurrence, something that happens on a daily basis. 
At the restaurant the waiter brings us our dinner and we note that the baked potato is filled with sour cream, 
even though we expressly requested "no sour cream". Projects are filled with misunderstandings between 
customers and project staff. What the customer's order (or more accurately what they think they order) is 
often not what they get. This is illustrated in a popular cartoon (Figure 10.1) called "I know that's what I 
said, but it's not what I meant!" The cartoon demonstrates the importance of establishing clear objectives. 



1 This content is available online at <http://cnx.Org/content/m31947/l.3/>. 
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Figure 10.1: I know that's what I said, but it's not what I meant! 



The need for establishing clear project objectives cannot be overstated. An objective or goal lacks clarity 
if, when shown to five people, it is interpreted in multiple ways. Ideally, if an objective is clear, you can 
show it to five people who, after reviewing it, hold a single view about its meaning. The best way to make 
an objective clear is to state it such a way that it can be verified. Building in measures can do this. It is 
important to provide quantifiable definitions to qualitative terms. 

For example, an objective of the team principle (project manager) of a Formula 1 racing team may be 
that their star driver, "finish the lap as fast as possible." That objective is filled with ambiguity. 

• How fast is "fast as possible?" Does that mean the fastest lap time (the time to complete one lap) or 
does it mean the fastest speed as the car crosses the start /finish line (that is at the finish of the lap)? 

• By when should the driver be able to achieve the objective? It is no use having the fastest lap after the 
race has finished, and equally the fastest lap does not count for qualifying, and therefore grid (starting) 
position, if it is performed during a practice session. 
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The ambiguity of this objective can be seen from the following example. The race lap record at the Circuit de 
Monaco of 1 min 14.439 sec was achieved by Ferrari's Michael Schumacher in 2004 (Figure 10.2). However, 
he achieved this on lap 23 of the race, but crashed on lap 45 of a 77 lap race! So while he achieved a fastest 
lap and therefore met the specific project goal of "finish the lap as fast as possible", it did not result in 
winning the race, clearly a different project goal. In contrast, the fastest qualifying time at the same event 
was by Renault's Jarno Trulli (1 min 13.985 sec), which gained him pole position for the race, in which he 
went on to win (Figure 10.3). In his case he also achieved the specific project goal of "finish the lap as fast 
as possible", but also the larger goal of winning the race! 




Figure 10.2: Despite achieving the project goal of the "finish the lap as fast as possible" Ferrari's 
Michael Schumacher crashed 21 laps later and did not finish the race. 




Figure 10.3: Renault's Jarno Trulli celebrating his win at the 2004 Monaco Grand Prix. 



The objective can be strengthened considerably if it is stated as follows: "To be able to finish the 3.340 
km lap at the Circuit de Monaco at the Monaco Grand Prix in 1 min 14.902 sec or less, during qualifying 
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on 23 May, 2009. This was the project objective achieved by Brawn GP's Jenson Button (Figure 10.4). 




MONACO ML, 

O r a n d PI ^^ \, 



MONA 

ff r n rf ' 




Figure 10.4: Jenson Button took his Brawn GP car to pole position at the Monaco Grand Prix with a 
lap time of 1 min 14.902 sec. He also went on to with the race, even though he did not achieve that lap 
time during the race. 



There is still some ambiguity in this objective; for example, it assumes the star driver will be driving the 
team's race car and not a rental car from Hertz! However, it clarifies the team principal's intent quite nicely. 
It should be noted that a clear goal is not enough. It must also be achievable. The team principal's goal 
becomes unachievable, for example, if he changes it to require his star driver finish the 3.340 km lap in 30 
seconds or less. 

To ensure the project's objectives are achievable and realistic, they must be determined jointly by man- 
agers and those who perform the work. Realism is introduced because the people who will do the work have 
a good sense of what it takes to accomplish a particular task. In addition, this process assures some level 
of commitment on all sides; management expresses its commitment to support the work effort and worker 
demonstrate their wiliness to do the work. 

Imagine you are an office manager and you have contracted a painter to paint your office. Your goal or 
objective is to have the office painted a pleasing blue color. Consider the following conversation that occurs 
after the job was finished: 
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Not only did you paint my office walls blue, 
but you painted the ceiling blue as well! 




You asked me to 

paint the room blue, 

and now you've got a 

blue room. 




Office Manager 



Contractor 



But the ceiling is oppressive! Ceilings should 
never be the same color as the walls. They 
should always be a lighter color. 




You asked for a blue room. 

You're lucky I didn't paint 

the floor blue as well. 




Office Manager 



Contractor 



Figure 10.5: The consequence of not making your objective clear. 



This conversation captures in a nutshell the essence of a major source of misunderstandings on projects: 
The importance of setting clear objectives. The office manager's description of how he wanted the room 
painted meant one thing to him and another to the painter. As a consequence, the room was not painted to 
the office manager's satisfaction. Had his objective been more clearly defined, he probably would have had 
what he wanted. 

Exercise 10.1 (Solution on p. 48.) 

How could you make the objective for painting a room clear such that the office manager gets what 
he wanted? 
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Solutions to Exercises in Chapter 10 

Solution to Exercise 10.1 (p. 47) 

The floor and all furniture will be covered by drop cloths prior to painting each of the 4 office walls, not 
including the door, base-boards, crown molding, window frames, windows, light switches, or power outlets 
that will be masked with painters tape. The walls should be painted using Behr paint in Sapphire Berry 
#550C-2 in the semi-gloss sheen, using a nylon/polyester 3" inch wide brush using a vertical brush stroke, 
applying two coats of paint, allowing 16 hours between coats, and be completed by Friday, November 7 
including removal of all protective tape and drop cloths. 

Of course this assumes the contractor knows which office to paint! But you get the idea. 



Chapter 11 
Project Planning 1 



After the project has been defined and the project team has been appointed, you are ready to enter the 
second phase in the project management life cycle: the detailed project planning phase. 

Project planning is the heart of the project life cycle, and tells everyone involved where you're going and 
how you're going to get there. The planning phase is where the project plans are documented, the project 
deliverables and requirements defined, and the project schedule created. It involves creating a set of plans 
to help guide your team through the execution and closure phases of the project. The plans created during 
this phase will help you to manage time, cost, quality, change, risk and related issues. It will also help you 
manage staff and external suppliers, to ensure that you deliver the project on time and within schedule. 

The project planning phase is often the most challenging phase for a project manager, as you need to 
make an educated guess of the staff, resources and equipment needed to complete your project. You may also 
need to plan your communications and procurement activities, as well as contract any 3rd party suppliers. 

The purpose of the project planning phase is: 

• Establish business requirements. 

• Establish cost, schedule, list of deliverables and delivery dates. 

• Establish resource plan. 

• Get management approval and proceed to the next phase. 

The basic processes of the project planning are: 

• Scope planning specifies the in-scope requirements for the project and facilitates creating the work 
breakdown structure. 

• Preparing the work breakdown structure specifies the breakdown of the project into tasks and 
sub tasks. 

• Project schedule development specifies the entire schedule of the activities detailing their sequence 
of execution. 

• Resource planning specifies who will do what work at which time of the project and if any special 
skills are needed to accomplish the project tasks. 

• Budget planning specifies the budgeted cost to be incurred in the completion of the project. 

• Procurement planning focuses on dealing with vendors outside of your company 

• Risk management planning charts the risks, contingency plan and mitigation strategies. 

• Quality planning for quality assurance to be applied to the project. 

• Communication planning on the communication strategy with all project stakeholders. 

The planning phase refines the project's objectives gathered during the initiation phase and plans the steps 
necessary to meet those objectives by further identifying the specific activities and resources required to com- 
plete the project. Now that these objectives have been recognized, they must be clearly articulated entailing 



1 This content is available online at <http://cnx.Org/content/m32170/l.7/>. 
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an in-depth scrutiny of the recognized objective. With such scrutiny, our understanding of the objective 
will change. Often the very act of trying to describe something precisely gives us a better understanding of 
what we are looking at. This articulation serves as the basis for the development of requirements. What this 
means is that after an objective has been clearly articulated (clearly stated) we can go about the business of 
stipulating in concrete terms what we have to do to achieve it. Obviously, if we do a poor job of articulating 
the objective, our requirements will be misdirected and the resulting project will not represent the true need. 
Users will often begin describing their objectives in qualitative language. The project manager must 
work with the user to provide quantifiable definitions to those qualitative terms. These quantifiable criteria 
include: schedule, cost, and quality measures. In the case of project objectives, these elements are used as 
measurements to determine project satisfaction and successful completion. Subjective evaluations can be 
removed with actual numbers. 

Example 11.1 

A web user may ask for a fast system. The quantitative example would be all screens must load in 
under 3 seconds. Describing the time limit in which the screen must load is specific and tangible. 
For that reason, you'll know that the requirement has been completed when the objective has been 
met. 

Example 11.2 

Let's say your company is going to produce a run of holiday eggnog. Your objective statement 
might be stated this way: Christmas Cheer, Inc. will produce two million cases of holiday eggnog 
to be shipped to our distributors by October 30 at a total cost of $1.5 million or less. The objective 
criteria in this statement are clearly stated and fulfillment of the project objective can be easily 
measured. Stakeholders will know the objective is met when the two million cases are produced 
and shipped by the due date within the budget stated. 

When articulating the project objectives you should follow the SMART rule: 

• Specific (get into the details). Objectives should be specific and written in clear, concise, and under- 
standable terms. 

• Measurable (use qualitative language so you know when you are finished). A requirement must have 
a measurable outcome; otherwise you will not be able to determine when you have delivered it. 

• Acceptable (to stakeholders). 

• Realistic (in terms of achievement). Objectives that are impossible to accomplish are not realistic and 
not attainable. Objectives must be centered in reality. 

• Time bound (deadlines not durations). Objectives should have a timeframe with an end date assigned 
to them. 

If you follow these principles, you'll be certain that your objectives meet the quantifiable criteria needed to 
measure success. 

11.1 Scope planning 

You always want to know exactly what work has to be done to finish your project BEFORE you start it. 
You've got a collection of team members, and you need to know exactly what they're going to do to build 
your product or meet the project's objectives. The scope planning process if the very first thing you do to 
manage your scope. Project scope planning is concerned with defining all of the work of the project and 
only the work needed to successfully meet the project objectives. The whole idea here is that when you 
start the project, you need to have a clear picture of all the work that needs to happen on your project, and 
as the project progresses, you need to keep that scope up to date and written down in the project's scope 
management plan. 
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11.1.1 How do you define the scope? 

You already got a head start on refining the project's objectives in quantifiable terms, but now you need to 
go a lot further and write down all of the deliverables that you and your team are going to produce over 
the course of the project. Deliverables include everything that you and your team produce for the project; 
anything that your project will deliver. The deliverables for your project include all of the products or 
services that you and your team are performing for the client, customer, or sponsor. But deliverables include 
more than that. They also include every single document, plan, schedule, budget, blueprint, and anything 
else that gets made along the way; including all of the project management documents you put together. 
Project deliverables are measurable outcomes, measurable results, or specific items that must be produced to 
consider the project or project phase completed. Deliverables like objectives must be specific and verifiable. 
All deliverables must be described in enough detail so that they can be differentiated from related 
deliverables. For example: 

• A twin engine plane versus a single engine plane. 

• A red marker versus a green marker. 

• A daily report versus a weekly report. 

• A departmental solution versus an enterprise solution. 

One of the project manager's primary functions is to accurately document the deliverables and requirements 
of the project and then manage the project so that they are produced according to the agreed upon criteria. 
Deliverables describe the components of the goals and objectives in a quantifiable way. Requirements are 
the specifications of the deliverables. 

11.1.2 Project requirements 

After all the deliverables are identified, the project manager needs to discover and document all of the 
requirements of the project (Figure 11.1). Requirements describe the characteristics of the deliverable. They 
may also describe functionality that the deliverable must have or specific conditions the deliverable must 
meet in order to satisfy the objective of the project. A requirement is an objective that must be met. The 
project requirements defined in the scope plan describe what a project is supposed to accomplish and how the 
project is supposed to be created and implemented. Requirements answer the following questions regarding 
the AS IS and TO BE states of the business: who, what where, when, how much, how does a business 
process work. 



I CANT START THE 
PROJECT BECAUSE THE 
USER WONT GIVE ME 
HIS REQUIREMENTS. 




START MAKING 
S0METHIN6 ANYWAY. 
OTHERWISE WELL 
LOOK UNHELPFUL. 




SO , OUR PLfcN IS TO 
CLEVERLY HIDE OUR 
COMPETENCE. 



YOU 

THINK 

TOO 

MUCH 





Figure 11.1: When you don't get project requirements. 
(2009). 



Copyright: United Feature Syndicate, Inc. 
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Requirements may include things like dimensions, ease of use, color, specific ingredients, and so on. If 
we go back to the example of the company producing holiday eggnog; one of the major deliverables is the 
cartons that hold the eggnog. The requirements for that deliverable may include carton design, photographs 
that will appear on the carton, color choices, etc. 

Requirements specify what the project deliverable should look like and what it should do. They can 
be divided into six basic categories, functional, non-functional, technical, user, business, and regulatory 
requirements. 

11.1.2.1 Functional requirements 

Functional requirements describe the characteristics of the deliverable, what emerges from the project in 
ordinary non-technical language. They should be understandable to the customers, and the customers 
should play a direct role in their development. Functional requirements are what you want the deliverable 
to do. 

Example 11.3 

If you were buying vehicles for a business your functional requirement might be; the vehicle should 
be able to take a load from a warehouse to a shop. 

Example 11.4 

For a computer system you may define what the system is to do; the system should store all details 
of a customer's order. 

The important point to note is that WHAT is wanted is specified, and not HOW it will be delivered. 

11.1.2.2 Non-functional requirements 

Non-functional requirements specify criteria that can be used to judge the product or service that your 
project delivers. They are restrictions or constraints to be placed on the deliverable and how to build it. 
Their purpose is to restrict the number of solutions that will meet a set of requirements. Using the vehicle 
example (Example 11.3); without any constraints, the functional requirement of a vehicle to take a load from 
a warehouse to a shop, the solutions being offered might result in anything from a large truck to a sports 
car! Non-functional requirements can be split into two types: performance and development. 
To restrict the types of solutions you might include these performance constraints: 

• It must take a load of at least one ton. 

• The load area must be covered. 

• The load area must have a height of at least 10 feet. 

Similarly, for the computer system example (Example 11.4), you might specify values for the generic types 
of performance constraints: 

• The response time for information to appear to a user. 

• The number of hours a system should be available. 

• The number of records a system should be able to hold. 

• The capacity for growth of the system. 

• The length of time a record should be held for auditing purposes. 

For the customer records example these might be: 

• The system should be available from 9 AM to 5 PM Monday to Friday. 

• The system should be able to hold 100,000 customer records initially. 

• The system should be able to add 10,000 records a year for 10 years. 

• A record should be fully available on the system for at least 7 years. 
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The important point with these examples is that they restrict the number of solution options that are offered 
to you by the developer. In addition to the performance constraints you may include some development 
constraints. 

There are three general types of development constraints: 



• 



Time: When a deliverable should be delivered 



• Resource: How much money is available to develop the deliverable 



• 



Quality: Any standards that are used to develop the deliverable, and develop methods, etc. 



11.1.2.3 Technical requirements 

Technical requirements emerge from the functional requirements, they answer the question, and how will 
the problem be solved this time; will it be solved technologically and/or procedurally. They answer how 
the system needs to be designed and implemented to provide required functionality and fulfill required 
operational characteristics. For example, in a software project, the functional requirements may stipulate 
that a data base system will be developed to allow access to financial data through a remote terminal; the 
corresponding technical requirements would spell out the architecture of the data structure, the language 
in which the database management system will be written, the hardware on which the system will run, 
telecommunication protocols that should be used and so forth. 

11.1.2.4 User requirements 

User requirements are what the users need to do with the system or product. They focus on the experience 
users need to have with the system, they can also reflect how the product will be designed, and define how 
test cases must be formulated. 

11.1.2.5 Business requirements 

Business requirements are the needs of the sponsoring organization, always from a management perspective. 
Business requirements are statements of the business rationale for the project. They are usually expressed 
in broad outcomes the business requires, rather than specific functions the system may perform. These 
requirements grow out of the vision for the product that, in turn, is driven by mission (or business) goals 
and objectives. 

11.1.2.6 Regulatory requirements 

Regulatory requirements can be internal or external and are usually non-negotiable. They are the restrictions, 
licenses and laws applicable to a product or business, imposed by the government. 

11.1.3 An example of requirements 

Automated teller machines (ATMs) can be used to illustrate a wide range of requirements (Figure 11.2). 
What are some of the physical features of these machines, and what kinds of functions do they perform for 
users? Why did banks put these systems in place? What high level business requirements did they have in 
mind? 
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Figure 11.2: A typical exterior automated teller machines (ATMs) 



The following represents one possible example of each type of requirement as they would be applied to a 
bank's external ATM. 



• ATM function requirement: The system shall provide users with the ability to select whether or 
not to produce a hardcopy transaction receipt before completing a transaction. 

• ATM non- functional requirement: All displays shall be in white 14 pt Arial text on black back- 
ground. 

• ATM user requirement: The system shall complete a standard withdrawal from a personal account, 
from login to cash, in less than two minutes for a first time user. 

• ATM business requirement: By providing superior service to our retail customers, Monumental 
Bank's ATM network will allow us to increase associated service fee revenue by 10% annually on an 
ongoing basis, using a baseline of December 2008. 

• ATM regulatory requirement: All ATMs shall connect to standard utility power sources within 
their civic jurisdiction, and be supplied with uninterruptible power source approved by said company. 

The effective specification of requirements is one of the most challenging undertakings project managers face. 
Inadequately specified requirements will guarantee poor project results. 

Documenting requirements is much more than just the process of writing down the requirements as the 
user sees them; it should cover not only what decisions have been made but also why they have been made. 
Understanding the reasoning that used to arrive at a decision is critical in avoiding repetition. For example, 
if a particular feature has been excluded because it is simply not feasible, that fact needs to be recorded. 
If it is not, then the project risks wasted work and repetition when a stakeholder requests the feature be 
reinstated during development or testing. Once the requirements are documented, have the stakeholders 
sign off on their requirements as a confirmation of what they desire. 

While the project manager is responsible for making certain the requirements are documented, it does 
not mean the project manager must perform this task. The project manager can enlist the help of stakehold- 
ers, business analysts, requirement analysts, business process owners, and other team members to conduct 
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the interviews and document the requirements. The project manager then reviews the requirements and 
incorporates them into the project documentation and project plan. 

11.2 Preparing the work breakdown structure 

Now that we have the deliverables and requirements well defined, the process of breaking down the work 
of the project via a work breakdown structure begins. The work breakdown structure (WBS) defines the 
scope of the project and breaks the work down into components that can be scheduled and estimated and 
easily monitored and controlled. The idea behind the work breakdown schedule is simple. You subdivide 
a complicated task into smaller tasks, until you reach a level that cannot be further subdivided. Anyone 
familiar with the arrangements of folders and files in a computer memory, or who has researched their 
ancestral family free, should be familiar with this idea. You stop breaking down the work when you reach 
a low enough level to perform an estimate of the desired accuracy. At that point, it is usually easier to 
estimate how long the small task will take and how much it will cost to perform than it would have been to 
estimate these factors at the higher levels. Each descending level of the WBS represents an increased level 
of detailed definition of the project work. 

As an example, if I want to clean a room, I might begin by picking up clothes, toys, and other things 
that have been dropped on the floor. I could use a vacuum cleaner to get dirt out of the carpet. I might take 
down the curtains and take them to the cleaners, then dust the furniture. All of these tasks are subtasks 
performed to clean the room. As for vacuuming the room, I might have to get the vacuum cleaner out of the 
closet, connect the hose, empty the bag, and put the machine back in the closet. These are smaller tasks to 
be performed in accomplishing the subtask called vacuuming. The diagram in Figure 11.3 shows how this 
might be portrayed in WBS format. 



1 .0 Mop floor 



1.1 Get mop and 
bucket out 



1.2 Mix cleaner with 
water in bucket 



2.0 Dust 



2.1 Coffe table 



* 2.2 Blinds 



1.3 Rinse out bucket 
and mop 



0.0 Clean Room 



-*- 3.2 Vacuum carpet 



3.0 Vacuum 



3.1 Get vacuum out of 
closet 



■*■ 3.3 Empty bag 



3.4 Connect hose and 
plug 



4.0 Pich up floor 












4.1 Toys 






L 


4.1.1 Put toys in 
box 








- 


4.2 Clothes 










- 


4.2.1 hang up in 
closet 



4.0 Clean curtains 



■* 4.1 Remove curtains 



4.2 Take to cleaners 



4.3 Hang curtains 



Figure 11.3: A work breakdown structure (WBS) for cleaning a room. 



It is very important to note that we do not worry about the sequence in which the work is performed or 
any dependencies between them when we do a WBS. That will be worked out when we develop the schedule. 
For example, under 3.0 Vacuum (in Figure 11.3), it would be obvious that 3.3 Vacuum carpet would be 
performed after 3.4 Connect hose and plug] However, you will probably find yourself thinking sequentially, 
as it seems to be human nature to do so. The main idea of creating a WBS is to capture all of the tasks, 
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irrespective of their order. So if you find yourself and other members of your team thinking sequentially, 
don't be too concerned, but don't get hung up on trying to diagram the sequence or you will slow down the 
process of task identification. 

A WBS can be structured any way it makes sense to you and your project. In practice, the chart 
structure is used quite often (as in the example in Figure 11.3) but it can be composed in outline form as 
well (Figure 11.4). 



CL&asw R&Crm/ 


1.0 Mop floor 


1.1 Qetwvop out of closet 


1.2 Mi^odeaner withwater in/ 


bucket 


1.3 HCme/ out bucket and/ Hop 


2.0 Vast 


2.1 Coffee/Table/ 


2.2 3Undy 


3.0 Vacuum/ 


3.1 Get vacuum/ out of closet 


3.2 Vacuum/ carpet 


3.3 Empty bag- 


3 A Connect Ho$e< and/plug^ 


4.0 PichUp floor 


4.2 Toyy 


H-.l.l Pattoyyin/toyboy/ 


4.2 Clothe* 


4-.2.1 Hangup Vn/cUnet 


5.0 Clean/ Cavtaim/y 


5.2 Reinove/Cavtavny 


5.2 Take/ to- Cleaner!,' 


5.3 HantyCurtainfr 



Figure 11.4: An outline format of a work breakdown structure (WBS) for cleaning a room. 



You'll notice that each element at each level of the WBS (in either Figure 11.3 or Figure 11.4) is assigned a 
unique identifier. This unique identifier is typically a number, and it's used to sum and track costs, schedules, 
and resources associated with WBS elements. These numbers are usually associated with the corporation's 
chart of accounts, which is used to track costs by category. Collectively, these numeric identifiers are known 
as the code of accounts. 

There are also many ways you can organize the WBS. For example, it can be organized by either deliv- 
erable or phase. The major deliverables of the project are used as the first level in the WBS. For example, 
if you are doing a multimedia project the deliverables might include producing a book, CD and a DVD 
(Figure 11.5). 
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1.0 Book 








- 


1.1 Writing 










- 


1.2 Publishing 




1.3 Producing 








1.4 Selling 





1.4.1 Retail 



1.4.2 Mail 



0.0 Multimedia Project 



2.0 CD 



2.1 Writing 



2.2 Recording 



2.3 Producing 



2.4 Selling 



2.4.1 Retail 



2.4.2 Mail 



3.0 DVD 
















3.1 Writing 












3.2 Recording 






3.3 Producing 












3.4 Selling 
















I 


3.4.1 Retail 




3.4.2 Mail 



Figure 11.5: An example of a work breakdown structure (WBS) based on project deliverable. 



Many projects are structured or organized by project phases. Each phase would represent the first level 
of the WBS and their deliverables would be the next level and so on (Figure 11.6). 



0.0 Project XXX 



1.0 Phase 1 



1.1 Process requirements 



1 .2 Data requirements 



1.2.1 Identify all data entries 



1.2.2 Load data modeling tool 



1.3 Conceptual design 



2.0 Phase 2 



2.1 Facilities 



2.2 Equipment 



2.3 People 



2.3.1 Fulltime 



2.3.2 Part time 



2.3.3 Temporary 



3.0 Phase 3 



3.1 Location 



3.1.1 Peru 



3.1.2 China 



3.1.3 Canada 



3.2 Surveys 



3.3 New designs 



Figure 11.6: An example of a work breakdown structure (WBS) based on project phase. 



As mentioned earlier, the project manager is free to determine the number of levels in the WBS based 
on the complexity of the project. You need to include enough levels to accurately estimate project time and 
costs but not so many levels that are difficult to distinguish between components. Regardless of the number 
of levels in a WBS, the lowest level in a WBS is called a work package. 
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Work packages are the components that can be easily assigned to one person, or team of people, with 
clear accountability and responsibility for completing the assignment. The work package level is where time 
estimates, costs estimates and resource estimates are determined. 

11.3 Project schedule development 

Now were off and running toward the development of our project schedule. In order to develop our schedule, 
we first need to define the activities, sequence them in the right order, estimate resources and estimate the 
time it will take to complete the tasks. 

The activity definition process is a further breakdown of the work package elements of the WBS. It docu- 
ments the specific activities needed to fulfill the deliverable detailed in the WBS. These are not deliverables 
but the individual units of work that must be completed to fulfill the deliverables. Activity definition uses 
everything we already know about the project to divide the work into activities that can be estimated. You 
might want to look at all the lessons learned from similar projects your company has done to get a god idea 
of what you need to do on the current one. 

Expert judgment in the form of project team members with prior experience developing project scope 
statements and WBS can help you define activities. You might also use experts in a particular field to help 
define tasks if you were asked to manage a project in a new domain; to help you understand what activities 
were going to be involved. It could be that you create an activity list and then have the expert review it 
and suggest changes. Alternatively, you could involve the expert from the very beginning and ask to have 
an activity definition conversation with him before even making your first draft of the list. 

Sometimes you start a project without knowing a lot about the work that you'll be doing later. Rolling 
wave planning lets you plan and schedule only the stuff that you know enough about to plan well. When 
you don't know enough about a project to come up with a complete activity list, you can use a planning 
component as a placeholder until you know more. These are extra items put at high levels in the WBS to 
allow you to plan for the unknown. 

11.3.1 A case study 

Susan and Steve have decided to tie the knot, but they don't have much time to plan their wedding. They 
want the big day to be unforgettable. They want to invite a lot of people and show them all a great time. 
They've always dreamed of a June wedding, but it's already January. Just thinking about all of the details 
involved is overwhelming. Somewhere around picking the paper for the invitations, the couple realizes they 
need help. Susan's been dreaming of the big day since she was 12, but it seems like there's so little time to 
do it all. 




Steve, we need some help. 



Don't worry. My sister's wedding planner was great. Let me give her a call. 
So saying Steve calls the wedding planner Sally. 
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We want everything to be perfect. 



i 



There is so much to do! Invitations, food, guests, and music. 




Oh no, we haven't even booked a place! 



i 



A And it's got to be done right. We can't print the initiations until we have the menu planned. 

We can't do the seating arrangements until we have the RSVPs. We aren't sure what kind of band to get 
for the reception, or should it be a DJ? We're just overwhelmed. 




My sister said you really saved her wedding. I know she gave you over a year to plan. 



A I But I've always dreamed of a June wedding, and I'm not willing to give that up. I know 
it's late, but Sally can you help us? 




Take it easy guys. I've got it under control. We've got a lot of people and activities to get 
under control. You guys really should have called six months ago, but we'll still make this wedding happen 
on time. 

There's a lot to get done before June. Sally's going to need to figure out what work needs to done before 
she does anything else. For this she starts to put together a to-do-list. 

• Invitations 

• Flowers 

• Wedding Cake 
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• Dinner Menu 

• Band 



Since there are so many different people involved in making the wedding go smoothly, it takes a lot of 
planning to make sure all of the work happens in the right order, gets done by the right people and doesn't 
take too long. Initially, Sally was worried that she didn't have enough time to make sure everything was 
done properly. But she knew that she had some powerful time management tools on her side when she took 
the job, and they'll help her make sure that everything will work out fine. 

To get started, Sally started arranging the activities in a work breakdown structure. This is part of the 
WBS Sally made for the wedding. 

Exercise 11.1 (Solution on p. 83.) 

Arrange the following activities into the WBS to show how the work items decompose into activities. 

• Shop for shoes 

• Create guest list 

• Tailoring and fitting 

• Shop for dress 

• Find caterer 

• Cater the wedding 

• Wait for RSVPs 

• Mail the invitations 

• Finalize the menu 

• Print the invitations 

• Choose the bouquet 



0.0 Wedding 



1.0 Invitations 










- 








- 





















2.0 Food 



3.0 Bridal 



11.3.2 Activity definition 

Now that the activity definitions for the work packages have been completed, the next task is to complete 
the activity list. The project activity list is a list of everything that needs to be done to complete your 
project, including all the activities that must be accomplished to deliver the work package. Next you want 
to define the activity attributes. Here's where the description of each activity is kept. All of the information 
you need to figure out; the order of the work should be here too. So any predecessor activities, successor 
activities or constraints should be listed in the attributes along with descriptions and any other information 
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about resources or time that you need for planning. The three main kinds of predecessors are finish-to-start 
(FS), start-to-start (SS) and finish-to-finish (FF). 

The most common kind of predecessor is the finish-to-start. It means that one task needs to be completed 
before another one can start. When you think of predecessors, this is what you usually think of, one thing 
needs to end before the next can begin. It's called finish-to-start because the first activity finish leads into 
the second activity's start (Figure 11.7). 



Print invitations 



Address 



Figure 11.7: An example of a finish-to-start (FS) predecessor. 



The start -to- start predecessor is a little less common, but sometimes you need to coordinate activities so 
they begin at the same time (Figure 11.8). 





Give toast 






Serve cake 





Figure 11.8: An example of a start-to-start (SS) predecessor. 



In the finish-to-finish predecessor it shows activities that finish at the same time (Figure 11.9). 
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Play "Here comes 
the bride" 










Bride walks down 
the isle 







Figure 11.9: An example of a finish-to-fiiiish (FF) predecessor. 



It is possible to have to have start-to-finish (SF) predecessors. This happens when activities require 
that a task be started before it can finish. An example might be that singing couldn't start until after the 
music had started. Keep in mind that tasks like that are pretty rare and almost never show up in network 
diagrams. In addition there are some particular types of predecessors that must be considered. 

11.3.2.1 External predecessors 

Sometimes your project will depend on things outside the work your doing. For the wedding, we are 
depending on the wedding party before us to be out of the reception hall in time for us to decorate. The 
decoration of the reception hall then depends on that as an external predecessor. 

11.3.2.2 Discretionary predecessors 

These are usually process or procedure driven or "best practice" techniques based on past experience. Using 
the wedding example: Steve and Susan really want the bridesmaids to arrive at the reception before the 
couple. There's no necessity there- it's just a matter of preference. 

11.3.2.3 Mandatory predecessors 

You can't address an invitation that hasn't been printed yet. So, printing invitations is a mandatory 
predecessor for addressing them. Mandatory predecessors are the kinds that have to exist just because of 
the nature of the work. 



11.3.3 Leads and lags 

Sometimes you need to give some extra time between activities. Lag time is when you purposefully put a 
delay between the predecessor task and the successor. For example, when the bride and her father dance, 
everybody waits a while before they join them (Figure 11.10). 
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Bride and father dance 



Everyone else dances 



Figure 11.10: A lag means making sure that one task waits a while before it gets started. 



Lead time is when you give a successor task some time to get started before the predecessor finishes 
(Figure 11.11). So you might want the caterer preparing dessert an hour before everybody is eating dinner. 





Serve dinner 



















Figure 11.11: A lead is when you let a task get started before its predecessor is done. 



11.3.4 Milestones 

All of the important checkpoints of your project are tracked as milestones. Some of them could be listed in 
your contract as requirements of successful completion; some could just be significant points in the project 
that you want to keep track of. The milestone list needs to let everyone know which are required and which 
are not. 

Some milestones for Susan and Steve's wedding might be: 

• Invitations sent 

• Menu finalized 

• Location booked 

• Bridesmaids' dresses fitted 

As you figure out which activities will need to be done, you may realize that the scope needs to change. 
When that happens, you need to create a change request and send it through the change control system. So 
back to our couple and their nuptial plan. 
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We just got the programs back from the printer and they're all wrong. 




The quartet cancelled. They had another wedding that day. 




Aunt Jane is supposed to sing at the service, but after what happened at her uncle's funeral, 
I think I want someone else to do it. 




Should we really have a pan flute player? I'm beginning to think it might be overkill. 



k 



Apparently! Maybe we should hold off printing the invitations until this stuff is worked out. 




OK, let's think about exactly how we want to do this. I think we need to be sure about 



how we want the service to go before we do any more printing. 



11.3.5 The activity sequencing process 

Now that we know what we have to do to make the wedding a success, we need to focus on the order of the 
work. Sally sat down with all of the activities she had defined for the wedding and decided to figure out 
exactly how they needed to happen. That's where she used the activity sequencing process. 

The activity attribute list Sally created had most of the predecessors and successors necessary written in 
it. This is where she thought of what comes first, second, third, etc. Sally's milestone list had major pieces 
of work written down and there were a couple of changes to the scope she had discovered along the way that 
were approved and ready to go. 

Example 11.5 

Milestone list: Steve and Susan had asked that the invitations be printed at least three months 
in advance to be sure that everyone had time to RSVP. That's a milestone on Sally's list. 
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Example 11.6 

Change request: When Sally realized that Steve and Susan were going to need another limo to 
take the bridesmaids to the reception hall, she put that change through change control- including 
running everything by Susan's mother- and it was approved. 



11.3.6 Creating the network diagram 

The first step in developing the schedule is to develop a network diagram of the WBS work packages. The 
network diagram is a way to visualize the interrelationships of project activities. Network diagrams provide 
a graphical view of the tasks and how they relate to one another. The tasks in the network are the work 
packages of the WBS. All of the WBS tasks must be included in the network because they have to be 
accounted for in the schedule. Leaving even one task out of the network could change the overall schedule 
duration, estimated costs and resource allocation commitments. 

The first step is to arrange the tasks from your WBS into a sequence (Figure 11.12). Some tasks can be 
accomplished at any time throughout the project where other tasks depend on input from another task or 
are constrained by time or resources. 
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Figure 11.12: The relationship between the work breakdown structure (WBS) and the network diagram. 



The WBS is not a schedule, but it is the basis for it; the network diagram is a schedule but is used 
primarily to identify key scheduling information that ultimately goes into user friendly schedule formats, 
such as milestone and Gantt charts. 
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The network diagram provides important information to the project team. It provides information about 
how the tasks are related (Figure 11.12), where the risk points are in the schedule, how long it will take as 
currently planned to finish the project, and when each task needs to begin and end. 

In our wedding planner example, Sally would look for relationships between tasks and determined what 
can be done in parallel and what activities needed to wait for others to complete. As an example, Figure 11.13 
shows how the activities involved in producing the invitations depend on one another. Showing the activities 
in rectangles and their relationships as arrows is called a precedence diagramming method (PDM). This kind 
of diagram is also called an activity on node (AON) diagram. 



This arrow shows a finish-to-start predecessor 
between the "pick calligrapher" and "address 




"Pick calligrapher" 

and "pick printer" 

have no 

predecessors 



Pick 
calligrapher 










Address 




Send 




invitations 




invitations 




The successor to "print 




v 








invuauons is aaaress 
invitations" 




Finish 


Pick printer 




Design 
invitations 




Print 












invitations 







"Printing invitations" 

depends on designing 

invitations" 



Figure 11.13: An example of an activity on node (AON) diagram. 



Another way to show how tasks relate is with the activity-on-arrow (AOA). Although activity-on-node 
(AON) is more commonly used and is supported by all project management programs, PERT is the best- 
known AOA-type diagram and is the historical basis of all network diagramming. The main difference is 
the AOA diagram is traditionally drawn using circles as the nodes, with nodes representing the beginning 
and ending points of the arrows or tasks. In the AOA network, the arrows represent the activities or tasks 
(Figure 11.14). 
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Figure 11.14: An example of an activity-on-arrow (AOA) network diagram. 



All network diagrams have the advantages as showing task interdependencies, start and end times, and 
the critical path (the longest path through the network) but the AOA network also has some disadvantages 
that limit the use of the method. 

The three major disadvantages of the AOA method are: 

• The AOA network can only show finish to start relationships. It is not possible to show lead and lag 
except by adding or subtracting time, which makes project tracking difficult. 

• There are instances when dummy activities can occur in an AOA network. Dummy activities are 
activities that show the dependency of one task on other tasks but for other than technical reasons. 
For example, a task may be dependent on another because it would be more cost effective to use 
the same resources for the two; otherwise the two tasks could be accomplished in parallel. Dummy 
activities do not have durations associated with them. They simply show that a task has some kind of 
dependence on another task. 

• AOA diagrams are not as widely used as AON simply because the latter are somewhat simpler to use 
and all project management software programs can accommodate AON networks, whereas not all can 
accommodate AOA networks. 



11.4 Resource planning 

In our case study it is clear that Steve and Susan have resource problems. Getting a handle on all of the 
tasks that have to be done is a great start, but it's not enough to know the tasks and the order they come in. 
Before you can put the final schedule together, you need to know who is going to each job, and the things 
they need available to them in order to do it! 




We've got so much to do! 
to do it all. I'm totally overwhelmed. 



Invitations, catering, music... and I've got no idea who's going 
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From this statement it is clear that Susan is worried about human resources. In comparison, Steve realizes 
that not all resources are people! 




And it's not just people! We need food, flowers, a cake, a sound system, and a venue! How 
do we get a handle on this? 

Resources are people, equipment, locations, or anything else that you need in order to do all of the 
activities that you planned for. Every activity in your activity list needs to have resources assigned to it. 
Before you can assign resources to your project, you need to know which ones you're authorized to use; 
that's called resource availability. Resource availability includes information about what resources you can 
use on your project and when they're available to you. Don't forget that some resources like consultants or 
training rooms have to be scheduled in advance, and they might only be available at certain times. You'll 
need to know this before you can finish planning your project. If you are starting to plan in January, a June 
wedding is harder to plan than one in December, because the wedding halls are all booked up in advance. 
That is clearly a resource constraint. You'll also need the activity list that you created earlier, and you'll 
need to know about how your organization typically handles resources. Once you've got a handle on these 
things, you're set for resource estimation. 

11.4.1 Estimating the resources 

The goal of activity resource estimating is to assign resources to each activity in the activity list. There are 
five tools and techniques for the activity resource estimating process. Some of them have technical sounding 
names, but they're all actually pretty sensible when you think about it. They should make sense to you 
when you think about what you have to do when you have to figure out what resources your project needs. 

• Expert judgment means bringing in experts who have done this sort of work before and getting their 
opinions on what resources are needed (Figure 11.15). 

• Alternative analysis means considering several different options for how you assign resources. This 
includes varying the number of resources as well as the kind of resources you use. Many times, 
there's more than one way to accomplish an activity and alternative analysis helps decide among the 
possibilities. 

• Published estimating data is something that project managers in a lot of industries use to help 
them figure out how many resources they need. They rely on articles, books, journals, and periodicals 
that collect, analyze, and publish data from other people's projects. 

• Project management software such as Microsoft project will often have features designed to help 
project managers estimate resource needs and constraints and find the best combination of assignments 
for the project. 

• Bottom-up estimating means breaking down complex activities into pieces and working out the 
resource assignments for each piece. It is a process of estimating these individual activities or costs 
and then adding these up together to come up with a total estimate. Here you estimate every scheduled 
activity individually and then roll up that estimate; or add them all together, to come up with a total. 
Bottom-up estimating is a very accurate means of estimating, provided the estimates at the schedule 
activity level are accurate. However, it takes a considerable amount of time to perform bottom-up 
estimating because every activity must be accessed and estimated accurately to be included in the 
bottom-up calculation. The smaller and more detailed the activity, the greater the accuracy and cost 
of this technique. 
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Figure 11.15: "I know nothing about the subject but I am happy to give you my expert opinion". 
Copyright Tribune Media Services (2007). 



In each of the following scenarios for planning Steve and Susan's wedding determine which of the five activity 
resource estimation tools and techniques is being used. 

Exercise 11.2 (Solution on p. 83.) 

Sally has to figure out what to do for the music at Steve and Susan's wedding. She considers using 
a DJ, a rock band, or a string quartet. 

Exercise 11.3 (Solution on p. 83.) 

The latest issue of Wedding Planner's Journal has an article on working with caterers. It includes 
a table that shows how many waiters work with varied guest-list sizes. 

Exercise 11.4 (Solution on p. 83.) 

There's a national wedding consultant who specializes in Caribbean themed weddings. Sally gets 
in touch with her to ask about menu options. 

Exercise 11.5 (Solution on p. 83.) 

Sally downloads and fills out a specialized spreadsheet that a project manager developed to help 
with wedding planning. 

Exercise 11.6 (Solution on p. 83.) 

There's so much work that has to be done to set up the reception hall that Sally has to break it 
down into five different activities in order to assign jobs. 

Exercise 11.7 (Solution on p. 83.) 

Sally asks Steve and Susan to visit several different caterers and sample various potential items 
for the menu. 

Exercise 11.8 (Solution on p. 83.) 

Sally calls up her friend who knows specifics of the various venues in their area for advice on which 
one would work best. 
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11,4,2 Estimating activity durations 

Once you're done with activity resource estimating, you've got everything you need to figure out how long 
each activity will take. That's done in a process called activity duration estimating. This is where you look 
at each activity in the activity list, consider the scope and the resources and estimate how long it will take 
to perform. 

Estimating the duration of an activity means starting with the information you have about that activity 
and the resources that are assigned to it, and then working with the project team to come up with an 
estimate. Most of the time you'll start with a rough estimate and then refine it to make it more accurate. 
You'll use these five tools and techniques to create the most accurate estimates: 

• Expert judgment will come from your project team members who are familiar with the work that 
has to be done. If you don't get their opinion, then there's a huge risk that your estimates will be 
wrong. 

• Analogous estimating is when you look at activities from previous projects that were similar to this 
one and look at how long it took to do similar work before. But this only works if the activities and 
the project team are similar! 

• Parametric estimating means plugging data about your project into a formula, spreadsheet, 
database, or computer program that comes up with an estimate. The software or formula that you use 
for parametric estimating is built on a database of actual durations from past projects. 

• Three-point estimates are when you come up with three numbers: a realistic estimate that's most 
likely to occur, an optimistic one that represents the best-case scenario, and a pessimistic one that 
represents the worst-case scenario. The final estimate is the average. 

• Reserve analysis means adding extra time to the schedule (called a contingency reserve or a buffer) 
to account for extra risk. 

In each of the following scenarios for planning Steve and Susan's wedding determine which of the five activity 
duration estimation tools and techniques is being used. 

Exercise 11.9 (Solution on p. 83.) 

Sally comes up with three estimates (one where everything goes wrong, one where some things go 
wrong, and one where nothing goes wrong) for printing invitations, and average them together to 
come up with a final number. 

Exercise 11.10 (Solution on p. 83.) 

Sally comes up with three estimates (one where everything goes wrong, one where some things go 
wrong, and one where nothing goes wrong) for printing invitations, and averages them together to 
come up with a final number. 

Exercise 11.11 (Solution on p. 83.) 

There are two different catering companies at the wedding. Sally asks the head chef at each of 
them to give her an estimate of how long it will take each of them to do the job. 

Exercise 11.12 (Solution on p. 83.) 

There's a spreadsheet Sally always uses to figure out how long it takes guest to RSVP. She enters 
the number of guests and their zip codes, and it calculates estimates for her. 

Exercise 11.13 (Solution on p. 83.) 

Sally's done four weddings that are very similar to Steve and Susan's, and in all four of them it 
took exactly the same amount of time for the caterers to set up the reception hall. 

You've got a list of activities, you know what resources are needed to actually do each activity, and you've 
got your estimation tools and techniques, now you have enough information to create the estimate! The 
activity duration estimates are an estimate of how long each activity in the activity list will take. This is a 
quantitative measure usually expressed in hours, weeks, days, or months. Any work period is fine, and you'll 
use different work periods for different jobs. A small job (like booking a DJ) may just take a few hours; a 
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bigger job (like catering-including deciding on a menu, ordering ingredients, cook food and serving guests 
on the big day) could take days. 

Another thing to keep in mind when estimating the duration of the activities, is determining the effort 
involved. Duration is the amount of the time that an activity takes, while effort if the total number of 
person-hours that are expended. If it takes two people six hours to carve the ice sculpture for the centerpiece 
of a wedding, the duration is six hours. But if two people worked on it for the whole time, it took twelve 
person-hours of effort to create! 

You'll also learn more about the specific activities while you're estimating them. That's something that 
always happens. You have to really think through all of the aspects of a task in order to estimate it. As you 
learn more about the specific activities remember to update the activity attributes. 

If we go back to our case study of the wedding we can see that while Sally has got a handle on how long 
things are going to take, that's not enough to get the job done. She still has some work to do before she's 
got the whole project under control. Steve and Susan know where they want to get married, and they've got 
the place booked now, but what about the caterer? They have no idea who's going to be providing food. 
And what about the band they want? Will the timing with their schedule work out? 







If the caterers come too early, the food will sit around under heat lamps! But, if they come 
too late, then the band won't have time to play. I just don't see how we'll ever work this out! 

It's not easy to plan for a lot of resources when they have tight time restrictions and overlapping con- 
straints. How do you figure out a schedule that makes everything fit together? You're never going to have 
the complete resource picture until your done building the schedule. And the same goes for your activity 
list and duration estimates too! It's only when you lay out the schedule that you'll figure out that some of 
your activities and durations didn't quite work. 

11.4,3 Project schedule 

The project schedule should be approved and signed off by stakeholders and functional managers. This 
assures they have read the schedule, understand the dates and resource commitments, and will likely cooper- 
ate. You'll also need to obtain confirmation that will be available as outlined in the schedule. The schedule 
cannot be finalized until you receive approval and commitment for the resource assignments outlined in it. 

Once the schedule is approved, it will become your baseline for the remainder of the project. Project 
progress and task completion will be monitored and tracked against the project schedule to determine if the 
project is on course as planned. 

The schedule can be displayed in a variety of ways, some of which are variations of what you have already 
seen. Project schedule network diagrams will work as schedule diagrams when you add the start and finish 
dates to each activity. These diagrams usually show the activity dependencies and critical path. 

The critical path method is an important tool for keeping your projects on track. Every network diagram 
has something that is called the critical path. It's the string of activities that, if you add up all of the 
durations, is longer than any other path through the network. It usually starts with the first activity in the 
network and usually ends with the last one. 




Aunt Jane is a vegetarian. That won't be a problem, right? 
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Well, let's see. What menu did we give the caterers? 



We didn't give it to them yet; because we won't have the final menu until everyone RSVPs 
and lets us know which entree they want. 



But they can't RSVP because we haven't sent out the invitations! What's holding that up? 




We're still waiting to get them back from the printer. We can't send them out if we don't 




Oh no! I still have to tell the printer what to print on the invitations, and what paper to 




But you were waiting on that until we finished the guest list. 



What a mess! 

Steve thought Aunt Jane being a vegetarian was just a little problem. But it turns out to be a lot bigger 
than either Steve or Susan realized at first! How'd a question about one guest's meal lead to such a huge 
mess? 

The reason that the critical path is critical is that every single activity on the path must finish on time 
in order for the project to come in on time. A delay in any one of the critical path activities will cause the 
entire project to be delayed (Figure 11.16). 



A delay here... 
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Figure 11.16: An example of problems that can be caused within the critical path. 



will cause 
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Knowing where your critical path is can give you a lot of freedom. If you know an activity is not on 
the critical path, then you know a delay in that activity may not necessarily delay the project. This can 
really help you handle emergency situations. Even better, it means that if you need to bring your project 
in earlier than was originally planned, you know that by adding resources to the critical path will be much 
more effective than adding them elsewhere. 

It's easy to find the critical path in any project! Of course, on a large project with dozens or hundreds 
of tasks, you'll probably use software like Microsoft Project to find the critical path for you. But when it 
does, it's following the same exact steps that are followed here. 



Step 1. Start with a network diagram. 



Look for paths by 
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Step 2. Find all the paths in the diagram. A path is any string of activities that goes from the start of the 
project to the end. 

Start -> Activity "A" -> Activity "B" -> Finish 

Start -> Activity "A" -> Activity "C" -> Finish 

Start -> Activity "D" -> Activity "E" -> Finish 

Step 3. Find the duration of each path by adding up the durations of each of the activities on the path. 
Start -> Activity "A" -> Activity "B" -> Finish = 4 + 7=11 

Start -> Activity "A" -> Activity "C" -> Finish = 4 + 2 = 6 
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Start -> Activity "D" -> Activity "E" -> Finish = 3+5 = 8 
Step 4. The first path has a duration of 11, which is longer than the other paths, so it's the critical path! 

The schedule can also be displayed using a Gantt chart (Figure 11.17). Gantt charts are easy to read and 
commonly used to display schedule activities. Depending on the software you use to display the Gantt 
chart, it might also show activity sequences, activity start and end dates, resource assignments, activity 
dependencies, and the critical path. Gantt charts are also known as bar charts. 
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Figure 11.17: An example of a Gantt chart. 



11.5 Budget Planning 

Every project boils down to money. If you had a bigger budget, you could probably get more people to 
do your project more quickly and deliver more. That's why no project plan is complete until you come up 
with a budget (Figure 11.18). But no matter whether your project is big or small, and no matter how many 
resources and activities are in it, the process for figuring out the bottom line is always the same. 
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Figure 11.18: Defining the priority of a budget! Copyright: United Features Syndicate, Inc. (2003). 



It is important to come up with detailed estimates of all the project costs. Once this is obtained, add up 
the cost estimates into a budget plan. It is now possible to track the project according to that budget while 
the work is ongoing. 

A lot of times you come into a project and there is already an expectation of how much it will cost or 
how much time it will take. When you make an estimate really early in the project and you don't know 
much about it, that estimate is called a rough order of magnitude estimate (or a ballpark estimate). It's 
expected that this estimate will become more refined as time goes on and you learn more about the project. 
Here are some more tools and techniques used to estimate cost: 

• Determine resource cost rates: People who will be working on the project all work at a specific 
rate. Any materials you will use to build the project (like wood or wiring) will be charged at a rate 
too. This just means figuring out what the rate for labor and materials will be. 

• Vendor bid analysis: Sometimes you will need to work with an external contractor to get your 
project done. You might even have more than one contractor bid on the job. This tool is all about 
evaluating those bids and choosing the one you will go with. 

• Reserve analysis: You need to set aside some money for cost overruns. If you know that your project 
has a risk of something expensive happening, better to have some cash lying around to deal with it. 
Reserve analysis means putting some cash away just in case. 

• Cost of quality: You will need to figure the cost of all your quality related activities into the overall 
budget, too. Since it's cheaper to find bugs earlier in the project than later, there are always quality 
costs associated with everything your project produces. Cost of quality is just a way of tracking the 
cost of those activities and is how much money it takes to do the project right. 

Once you apply all the tools in this process, you will arrive at an estimate for how much your project will 
cost. It's always important to keep all of your supporting estimate information, too. That way, you know 
the assumptions you made when you were coming up with your numbers. Now you are ready to build your 
budget plan. 



11.6 Procurement planning 

Procurement management follows a logical order. First, you plan what you need to contract; then you plan 
how you'll do it. Next, you send out your contract requirements to sellers. They bid for the chance to work 
with you. You pick the best one, and then you sign the contract with them. Once the work begins, you 
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monitor it to make sure the contract is being followed. When the work is done, you close out the contract 
and fill out all the paperwork. 

You will need to start with a plan for the whole project. You need to think about all of the work that 
you will contract out for your project before you do anything else. You will want to plan for any purchases 
and acquisitions. Here's where you take a close look at your needs, to be sure that you really need to create 
a contract. You figure out what kinds of contracts make sense for your project, and you try to define all of 
the parts of your project that will be contracted out. 

Contract planning is where you plan out each individual contract for the project work. You work out 
how you manage the contract, what metrics it will need to meet to be considered successful, how you'll pick 
a seller, and how you'll administer the contract once the work is happening. 

The procurement management plan details how the procurement process will be managed. It includes 
the following information: 

• The types of contracts you plan to use, and any metrics that will be used to measure the contractor's 
performance. 

• The planned delivery dates for the work or products you are contracting. 

• The company's standard documents you will use. 

• How many vendors or contractors are involved and how they will be managed. 

• How purchasing may impact the constraints and assumptions of the project plan. 

• Coordination of purchasing lead times with the development of the project schedule. 

• Identification of prequalified sellers (if known) . 

The procurement management plan like all other management plans becomes a subsidiary of the project 
management plan. Some tools and techniques you may use during the procurement planning stage include 
make or buy analysis and defining the contract type. 

11.6.1 Make or buy analysis 

This means figuring out whether or not you should be contracting the work or doing it yourself. It could also 
mean deciding whether to build a solution to your problem or buy one that is already available. Most of the 
same factors that help you make every other major project decision will help you with this one. How much 
does it cost to build it as opposed to buy it? How will this decision affect the scope of your project? How 
about project schedule? Do you have time to do the work and still meet your commitments? As you plan 
out what you will and won't contract, you need to have thought through your reasoning pretty carefully. 

There are some resources (like heavy equipment) that your company can buy, rent, or lease depending on 
the situation. You'll need to examine leasing versus buying costs and determine the best way to go forward. 

11.6.2 Contract types 

You should know a little bit about the major kinds of contracts available to you so that you choose the one 
that creates the most fair and workable deal for you and the contractor. Some contracts are fixed price: no 
matter how much time or effort goes into them, you always pay the same (Figure 11.19). Some are cost 
reimbursable also called cost plus (Figure 11.20). This is where the seller charges you for the cost of doing 
the work plus some fee or rate. The third major kind of contract is time and materials (Figure 11.21). That's 
where the buyer pays a rate for the time spent working on the project and also pays for all the materials 
used to do the work. 
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Effort 



Figure 11.19: A fixed price contract the cost (or revenue to the vendor) is constant regardless of effort 
applied or delivery date. 




Effort 



Figure 11.20: In a cost reimbursable or cost plus contract, the seller is guaranteed a specific fee. 
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Effort 



Figure 11.21: In a time and materials contract the cost (or revenue to the vendor) increases with 
increased effort. 



11.7 Risk management planning 

Even the most carefully planned project can run into trouble. No matter how well you plan, your project can 
always run into unexpected problems. Team members get sick or quit, resources that you were depending 
on turn out to be unavailable, even the weather can throw you for a loop. For example, Hurricane Ike. So 
does that mean that you're helpless against unknown problems? No! You can use risk planning to identify 
potential problems that could cause trouble for your project, analyze how likely they'll be to occur, take 
action to prevent the risks you can avoid, and minimize the ones that you can't. 

A risk is any uncertain event or condition that might affect your project. Not all risks are negative. Some 
events (like finding an easier way to do an activity) or conditions (like lower prices for certain materials) can 
help your project. When this happens, we call it an opportunity; but it's still handled just like a risk. 

There are no guarantees on any project. Even the simplest activity can turn into unexpected problems. 
Any time there's anything that might occur on your project and change the outcome of a project activity, 
we call that a risk. A risk can be an event (like a hurricane) or it can be a condition (like an important part 
being unavailable). Either way, it's something that may or may not happen ...but if it does, then it will force 
you to change the way you and your team will work on the project. 

If your project requires that you stand on the edge of a cliff, then there's a risk that you could fall 
(Figure 11.22). If it's very windy out or if the ground is slippery and uneven, then falling is more likely. 
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Figure 11.22: Potential ways to handle risk in a project. 



When you're planning your project, risks are still uncertain: they haven't happened yet. But eventually, 
some of the risks that you plan do happen. And that's when you have to deal with them. There are four 
basic ways to handle a risk. 

1. Avoid: The best thing that you can do with a risk is to avoid it. If you can prevent it from happening, 
it definitely won't hurt your project. The easiest way to avoid this risk is to walk away from the cliff 
(Figure 11.22), but that may not be an option on this project. 

2. Mitigate: If you can't avoid the risk, you can mitigate it. This means taking some sort of action that 
will cause it to do as little damage to your project as possible (Figure 11.22). 

3. Transfer: One effective way to deal with a risk is to pay someone else to accept it for you (Figure 11.22). 
The most common way to do this is to buy insurance. 

4. Accept: When you can't avoid, mitigate, or transfer a risk, then you have to accept it (Figure 11.22). 
But even when you accept a risk, at least you've looked at the alternatives and you know what will 
happen of it occurs. If you can't avoid the risk, and there's nothing you can do to reduce its impact, 
then accepting it is your only choice. 

By the time a risk actually occurs on your project, it's too late to do anything about it. That's why you 
need to plan for risks from the beginning and keep coming back to do more planning throughout the project. 

The risk management plan tells you how you're going to handle risk in your project. It documents how 
you'll access risk on the project, who is responsible for doing it, and how often you'll do risk planning (since 
you'll have to meet about risk planning with your team throughout the project.) 

The plan has parts that are really useful for managing risks. 

• Risk categories that you'll use to classify your risks. Some risks are technical, like a component that 
might turn out to be difficult to use. Others are external, like changes in the market or even problems 
with the weather. 

• Risk breakdown structure (RBS) is a great tool for managing your risk categories. It looks like a 
WBS, except instead of tasks it shows how the risks break down into categories. 

It's important to come up with guidelines to help you figure out how big a risk's impact is. The impact tells 
you how much damage the risk will cause to your project. A lot of projects classify impact on a scale from 
minimal to severe, or from very low to very high. The plan should also give you a scale to help figure out 
the probability of the risk. Some risks are very likely; others aren't. 
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11.8 Quality planning 

It's not enough to make sure you get it done on time and under budget. You need to be sure you make the 
right product to suit your stakeholders' needs. Quality means making sure that you build what you said you 
would and that you do it as efficiently as you can. That means trying not to make too many mistakes and 
always keeping your project working toward the goal of creating the right product! 

Everybody "knows" what quality is. But the way the word is used in everyday life is a little different that 
how it is used in project management. Just like the tripe constraint, scope, cost, and schedule- you manage 
quality on your project by setting goals and taking measurements. That's why you need to understand the 
quality levels your stakeholders believe are acceptable, and that your projects meet those targets; just like 
it needs to meet their budget and schedule goals. 

• Customer satisfaction is about making sure that the people who are paying for the end product 
are happy with what they get. When the team gathers requirements for the specification, they try to 
write down all of the things that the customers want in the product so that you know how to make 
them happy. Some requirements can be left unstated, too. Those are the ones that are implied by the 
customer's explicit needs. For example: some requirements are just common sense, like a product that 
people hold can't be made from toxic chemicals that kill you. It might not be stated, but it's definitely 
a requirement! 

• Fitness to use is about making sure that the product you build has the best design possible to fit the 
customer's needs. Which would you choose: a product that's beautifully designed, well constructed, 
solidly built and all around pleasant to look at but does not do what you need, or a product that does 
what you want despite being really ugly and hard to use? You'll always choose the product that fits 
your needs, even if it's seriously limited. That's why it's important that the product both does what 
it is supposed to do and does it well. For example: you could pound in a nail with a screwdriver, but 
a hammer is better fit for the job. 

• Conformance to requirements is the core of both customer satisfaction and fitness to use, and is 
a measure of how well your product does what you intend. Above all, your product needs to do what 
you wrote down in your requirements document. Your requirements should take into account what 
will satisfy your customer and the best design possible for the job. That means conforming to both 
stated and implied requirements. 

In the end, your product's quality is judged by whether you built what you said you would build. 

Quality planning focuses on taking all of the information available to you at the beginning of your project 
and figuring out how you will measure your quality and prevent defects. Your company should have a quality 
policy that tells how it measures quality across the organization. You should make sure your project follows 
the company policy and any governmental rules or regulations on how you need to plan quality for your 
project. 

You need to plan out which activities you're going to use to measure the quality of the product of your 
project. And you need to be sure the activities you plan are going to pay off in the end. So you'll need 
to think about the cost of all the quality-related activities you want to do. Then you'll need to set some 
guidelines for what you going to measure against. Finally, you'll need to design the tests you're going to run 
when the product is ready to be tested. 

11.8.1 Quality planning tools 

The following represents the quality planning tools available to the project manager. 

• Cost benefit analysis is looking at how much your quality activities will cost versus how much you 
will gain from doing them. The costs are easy to measure; the effort and resources it takes to do them 
are just like any other task on your schedule. Since quality activities don't actually produce a product, 
it is harder for people to measure the benefit sometimes. The main benefits are less re-work, higher 
productivity and efficiency and more satisfaction from both the team and the customer. 
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• Benchmarking means using the results of quality planning on other projects to set goals for your 
own. You might find that the last project in your company had 20% fewer defects than the one before 
it. You should want to learn from a project like that and put in practice any of the ideas they used 
to make such a great improvement. Benchmarks can give you some reference points for judging your 
own project before you even get started with the work. 

• Design of experiments is the list of all the kinds of tests you are going to run on your product. 
It might list all the kinds of test procedures you'll do, the approaches you'll take, and even the tests 
themselves. (In the software world, this is called test planning). 

• Cost of quality is what you get when you add up the cost of all the prevention and inspection 
activities you are going to do on your project. It doesn't just include the testing. It includes any time 
spent writing standards, reviewing documents, meeting to analyze the root causes of defects, re-work 
to fix the defects once they're found by the team; absolutely everything you do to ensure quality on 
the project. 

Cost of quality can be a good number to check whether your project is doing well or having trouble. Say 
your company tracks cost of quality on all of its projects. Then you could tell if you were spending more or 
less than they are to get your project up to quality standards. 

Once you have your quality plan, you know your guidelines for managing quality on your project. Your 
strategies for monitoring your project quality should be included in the plan, as well as the reasons for all 
the steps you are taking. It's important that everyone on the team understand the rationale behind the 
metrics being used to judge success or failure of the project. 

11.9 Communication planning 

Communications management is about keeping everybody in the loop. Have you ever tried talking to 
someone in a really loud, crowded room? That's what running a project is like if you don't get a handle on 
communications. The communications planning process concerns defining the types of information you're 
going to deliver, to whom, the format for communicating the information and when. It turns out that 90% 
of a project manager's job is spent on communication so it's important to make sure everybody gets the 
right message at the right time. 

The first step in defining your communication plan is figuring out what kind of communication your 
stakeholders need from the project so that they can make good decisions. This is called the communications 
requirements analysis. Your project will produce a lot of information; you don't want to overwhelm your 
stakeholders with all of it. Your job here is to figure out what they feel is valuable. Communicating valuable 
information doesn't mean you always paint a rosy picture. Communications to stakeholders may consist of 
either good news or bad news- the point is that you don't want to bury stakeholders in too much information 
but give them enough so that they're informed and can make appropriate decisions. 

Communications technology has a major impact on how you can keep people in the loop. This examines 
the methods (or technology) used to communicate the information to, from and among the stakeholders. 
Methods of communicating can take many forms, such as written, spoken, e-mail, formal status reports, 
meetings, online databases, online schedules, project websites and so forth. You should consider several 
factors before deciding what methods you'll choose to transfer information. The timing of the information 
exchange or need for updates is the first factor. It's a lot easier for people to get information on their 
projects if it's accessible through a web site, than if all your information is passed around by paper memos. 
Do you need to procure new technology or systems, or are there systems already in place that will work? 
The technologies available to you will definitely figure into your plan of how you will keep everyone notified 
of project status and issues. Staff experience with the technology is another factor. Are there project team 
members and stakeholders experienced at using this technology, or will you need to train them? Finally, 
consider the duration of the project and the project environment. Will the technology you're choosing work 
throughout the life of the project or will it have to be upgraded or updated at some point? And how does 
the project team function? Are they located together or spread out across several campuses or locations? 
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The answers to these questions should be documented in the communication plan. 

All projects require sound communication plans, but not all projects will have the same types of com- 
munication or the same methods for distrusting the information. The communication plan documents the 
types of information needs the stakeholders have, when the information should be distributed and how the 
information will be delivered. 

The type of information you will typically communicate includes project status, project scope statements, 
and scope statement updates, project baseline information, risks, action items, performance measures, project 
acceptance and so on. What's important to know now is that the information needs of the stakeholders should 
be determined as early in the planning phase of the project management lifecycle as possible so that as you 
and your team develop project planning documents, you already know who should receive copies of them 
and how they should be delivered. 

11.10 Bringing it all together 

Believe it or not, we have officially completed the planning phase of the project management lifecycle. The 
project plan is the approved, formal, documented plan that's used to guide you throughout the project 
execution phase. The plan is made up of all the processes of the planning phase. It is the map that tells you 
where you're going and how to perform the activities of the project plan during the project execution phase. 
It serves several purposes; the most important of which is tracking and measuring project performance. 
The project plan is critical in all communications you'll have from here forward with the stakeholders, 
management, and customers. The project plan encompasses everything we talked about up to now and is 
represented in a formal document or collection of documents. This document contains the project scope, 
deliverables, assumptions, risks, WBS, milestones, project schedule, resources, communication plan, the 
project budget and any procurement needs. It becomes the baseline you'll use to measure and track progress 
against. It is also used to help you control the components that tend to stray away from the original plan 
so you can get them back on track. 

The project plan is used as a communication and information tool for stakeholders, team members and 
the management team. They will use the project plan to review and gauge progress as well. Your last 
step in the planning phase is obtaining sign-off of the project plan from stakeholders, the sponsor and the 
management team. If they've been an integral part of the planning processes all along (and I know you know 
how important this is), obtaining sign-off of the project plan should simply be a formality. 
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Solutions to Exercises in Chapter 11 

Solution to Exercise 11.1 (p. 60) 



0.0 Wedding 



1.0 Invitations 



2.0 Food 



1.1 Create guest list 



1.2 Print the invitations 



1.3 Mail the invitations 



2.1 Find caterer 



■*■ 2.2 Finalize menu 



2.3 Cater wedding 



1 .4 Wait for RSVPs 



Solution to Exercise 11.2 (p. 69) 

Alternative analysis. 
Solution to Exercise 11.3 (p. 69) 

Published estimating data. 
Solution to Exercise 11.4 (p. 69) 

Expert judgment. 
Solution to Exercise 11.5 (p. 69) 

Project management software. 
Solution to Exercise 11.6 (p. 69) 

Bottom-up estimating 
Solution to Exercise 11.7 (p. 69) 

Alternative analysis 
Solution to Exercise 11.8 (p. 69) 

Expert judgment. 
Solution to Exercise 11.9 (p. 70) 

Three-point estimate. 
Solution to Exercise 11.10 (p. 70) 

Three-point estimate. 
Solution to Exercise 11.11 (p. 70) 

Expert judgment. 
Solution to Exercise 11.12 (p. 70) 

Parametric estimating. 
Solution to Exercise 11.13 (p. 70) 

Analogous estimating. 



3.0 Bridal 



3.1 Shop for dress 



3.2 Shop for shoes 



3.3 Choose bouquet 



3.4 Tailoring and fitting 
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Chapter 12 

Project Execution 1 



After you have carefully planned your project, you will be ready to start the project execution phase, the 
third phase of the project management life cycle. The execution phase involves putting the project plan into 
action. It's here that the project manager will coordinate and direct project resources to meet the objectives 
of the project plan. As the project unfolds, it's the project manager's job to direct and manage each activity 
on the project, every step of the way. That's what happens in the execution phase of the project lifecycle; 
you simply follow the plan you've put together and handle any problems that come up. 

The execution phase is where you and your project team actually do the project work to produce the 
deliverables. The word deliverable means anything your project delivers. The deliverables for your project 
include all of the products or services that you and your team are performing for the client, customer or 
sponsor including all the project management documents that you put together. 

The steps undertaken to build each deliverable will vary depending on the type of project you are under- 
taking, and cannot therefore be described here in any real detail. For instance engineering and telecommuni- 
cations projects will focus on using equipment, resources and materials to construct each project deliverable, 
whereas computer software projects may require the development and implementation of software code rou- 
tines to produce each project deliverable. The activities required to build each deliverable will be clearly 
specified within the project requirements document and project plan accordingly. 

Your job as project manager is to direct the work, but you need to do more than deliver the results. 
You also need to keep track of how well your team performed. The executing phase keeps the project plan 
on track with careful monitoring and control processes to ensure the final deliverable meets the acceptance 
criteria set by the customer. This phase is typically where approved changes are implemented. 

Most often changes are identified through looking at performance and quality control data. Routine 
performance and quality control measurements should be evaluated on a regular basis throughout the exe- 
cution phase. Gathering reports on those measurements will help you determine where the problem is and 
recommend changes to fix it. 

12.1 Change control 

When you find a problem, you can't just make a change, because what if it's too expensive, or will it take 
too long? You will need to look at how it affects the triple constraint (time, cost, scope) and how they 
impact quality. You will then have to figure out if it is worth making the change. Change control is a set of 
procedures that let you make changes in an organized way. 

Anytime you need to make a change to your plan, you need to start with a change request (Figure 12.1). 
This is a document that either you or the person making the request needs to create. Any change to your 
project needs to be documented so you can figure out what needs to be done, by when, and by whom. 



lr This content is available online at <http://cnx.Org/content/m32189/l.l/>. 
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Figure 12.1: Is it too late to add the client's wish list of features to the project? 



Once the change request is documented, it is submitted to a change control board. A change control 
board is a group of people who consider changes for approval. Not every change control system has a board 
but most do. The change request could also be submitted to the project sponsor or management for review 
and approval. Putting the recommended changes through change control will help you evaluate the impact 
and update all the necessary documents. Not all changes are approved, but if the changes and repairs are 
approved, you send them back to the team to put them in place. 

The execution phase will utilize the most project time and resources and as a result, costs are usually 
the highest during the executing phase. Project managers will also experience the greatest conflicts over 
schedules in this phase. You may find as your monitoring your project, the actual time it is taking to do 
the scheduled work is taking longer than the amount of time you planned. If you evaluate the impact of the 
change and find that it won't have an impact on the project triple constraint, then you can make the change 
without going through change control. 

When you absolutely have to meet the date and you are running behind, you can sometimes find ways to 
do activities more quickly by adding more resources to critical path tasks. That's called crashing. Crashing 
the schedule means adding resources or moving them around to shorten it. Crashing ALWAYS costs more 
and doesn't always work! There's no way to crash a schedule without raising the overall cost of the project. 
So, if the budget is fixed and you don't have any extra money to spend, you can't use this technique. 

Sometimes you've got two activities planned to occur in sequence, but you can actually do them at the 
same time. This is called fast-tracking the project. On a software project, you might do both your user 
acceptance testing (UAT) and your functional testing at the same time, for example. This is pretty risky. 
There's a good chance you might need to redo some of the work you have done concurrently. Crashing and 
fast tracking are schedule compression tools. Managing schedule change means keeping all of your schedule 
documents up to date. That way, you will always be comparing your results to the right plan. 

After the deliverables have been physically constructed and accepted by the customer a phase review is 
carried out to determine whether the project is complete and ready for closure. 



Chapter 13 

Project Closeout 1 



Every project needs to end and that's what project closeout is all about in the last phase of the project 
Hfecycle. The whole point of the project is that you need to deliver what you promised. By making sure you 
delivered everything you said you would, you make sure that all stakeholders are satisfied and all acceptance 
criteria has been met. Once that happens, your project can finish (Figure f3.f). 




Figure 13.1: The potential unwanted consequences of finishing a project on time and within budget! 



Project closeout is often the most often neglected phase of all the project lifecycle. Once the project is 
over, it's easy to pack things up, throw some files in a drawer, and start moving right into the initiation 
phase of the next project. Hold on! You're not done yet! 

The key activity in project closeout is gathering project records and disseminating information to for- 
malize acceptance of the product, service or project as well as to perform project closure. As the project 
manager, you will want to review project documents to make certain they are up-to-date. For example, 
perhaps some scope change requests were implemented that changed some of the characteristics of the final 
product. The project information you are collecting during this phase should reflect the characteristics and 
specifications of the final product. Don't forget to update your resource assignments as well. Some team 



1 This content is available online at <http://cnx.org/content/m32188/!. l/>. 
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members will have come and gone over the course of the project; you need to double-check that all the 
resources and their roles and responsibilities are noted. 

Once the project outcomes are documented, you'll request formal acceptance from the stakeholders or 
customer. They're interested in knowing if the product or service of the project meets the objectives the 
project set out to accomplish. If your documentation is up-to-date, you'll have the project results at hand 
to share with them. 

13.1 Lessons learned 

Project closeout is also concerned with analyzing the project management processes to determine their 
effectiveness and to document lessons learned. Lessons learned are used to document the successes and 
failures of the project. As an example, lessons learned document the reasons why specific corrective actions 
were taken, their outcomes, the causes of performance variances, unplanned risks that occurred, mistakes 
that were made and could have been avoided and so on. 

Unfortunately, sometimes projects do fail. There are things that can be learned from the failure of a 
project (as well from successful projects), and this information should be documented for future reference. 
Lessons learned can be some of the most valuable information you'll take away from any project. We can all 
learn from our experiences, and what better way to have more success on your next project than to review 
a similar past project's lessons learned document? But it is important not to forget the lessons learned! 

13.2 Contract closure 

Contracts come to a close just as projects come to a close. Contract closure is concerned with completing 
and settling the terms of the contract. It supports the project closeout process because the contract closure 
process determines if the work described in the contract was completed accurately and satisfactorily. Keep 
in mind that not all projects are performed under contract so not all projects require the contract closure 
process. Obviously, this process applies only to those phases, deliverables or portions of the project that 
were performed under contract. 

Contract closure updates the project records detailing the final results of the work on the project. Con- 
tracts may have specific terms or conditions for completion and closeout. You should be aware of these 
terms or conditions so that project closeout isn't held up because you missed an important detail. If you 
are administering the contract yourself, be sure to ask your procurement department if there are any special 
conditions that you should be aware of so that your project team doesn't inadvertently delay contract project 
closure. 

One of the purposes of contract closure process is to provide formal notice to the seller- usually in written 
form, that the deliverables are acceptable and satisfactory or have been rejected. If the product or service 
does not meet the expectations, the vendor will need to correct the problems before you issue a formal 
acceptance notice. Hopefully, quality audits have been performed during the course of the project and the 
vendor was given the opportunity to make corrections earlier in the process than the closing phase. It's not a 
good idea to wait until the very end of the project and then spring all the problems and issues on the vendor 
at once. It's much more efficient to discuss problems with your vendor as the project progresses because it 
provides the opportunity for correction when the problems occur. 

If the product or service does meet the project's expectation and is acceptable, formal written notice 
to the seller is required indicating that the contract is complete. This is the formal acceptance and closure 
of the contract. It's your responsibility as the project manager to document the formal acceptance of the 
contract. Many times the provisions for formalizing acceptance and closing the contract are spelled out in 
the contract itself. 

If you have a procurement department handling the contract administration, they will expect you to 
inform them when the contract is complete and will in turn follow the formal procedures to let the seller 



89 

know the contract is complete. However, you'll still note the contract completion in your copy of the project 
records. 

13.3 Releasing project team 

Releasing project team members is not an official process. However, it should be noted that at the conclusion 
of the project, you will release your project team members, and they will go back to their functional managers 
or get assigned to a new project. You will want to keep their managers, or other project managers, informed 
as you get closer to project completion, so that they have time to adequately plan for the return of their 
employees. Start letting them know a few months ahead of time what the schedule looks like and how soon 
they can plan on using their employees on new projects. This gives the other managers the ability to start 
planning activities and scheduling activity dates. 

13.4 Celebrate! 

The project team should celebrate their accomplishment, and the project manager should officially recognize 
their efforts and thank them for their participation and officially close the project. A celebration helps team 
members formally recognize the project end and brings closure to the work they've done. It also encourages 
them to remember what they've learned and to start thinking about how their experiences will benefit them 
and the organization during the next project (Figure 13.2). 




Figure 13.2: Celebrate! Your project is over. . . at least until the next one. 
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Chapter 14 

A Glossary of Project Management 
Terms 1 



Every discipline has its own vocabulary, and project management is no exception. Part of the process 
of successfully deploying project management in your organization is to standardize the terminology. That 
way, when one person talks about risks, scope, issues, requirements, and other project management concerns, 
everyone else knows what he or she is referring to. This glossary contains common terms used in project 
management and can help start the standardization process. 

14.1 Assumption 

There may be external circumstances or events that must occur for the project to be successful (or that 
should happen to increase your chances of success). If you believe that the probability of the event occurring 
is acceptable, you could list it as an assumption. An assumption has a probability between and 100%. 
That is, it is not impossible that the event will occur (0%) and it is not a fact (100%). It is somewhere 
in between. Assumptions are important because they set the context in which the entire remainder of the 
project is defined. If an assumption doesn't come through, the estimate and the rest of the project definition 
may no longer be valid. 

14.2 BAC 

Budget at completion (BAC) is the sum of all budgets allocated to a project. 

14.3 Backward pass 

Calculation of the latest finish times by working from finish-to-start for the uncompleted portion of a network 
of activities. 

14.4 Balanced matrix 

An organizational matrix where functions and projects have the same priority. 



lr This content is available online at <http://cnx.Org/content/m31434/l.6/>. 
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14.5 Bar chart 

A view of the project schedule that uses horizontal bars on a time scale to depict activity information; 
frequently called a Gantt chart. 

14.6 Baseline 

The value or condition against which all future measurements will be compared. 

14.7 Baseline cost 

The amount of money an activity was intended to cost when the baseline plan was established. 

14.8 Baseline dates 

Original planned start and finished dates for an activity. Used to compare with current planned dates to 
determine any delays. Also used to calculate budgeted cost of work scheduled in earned value analysis. 

14.9 Baseline plan 

The original plan (for a project, a work package, or an activity), plus or minus approved changes. Usually 
used with a modifier, e.g., cost baseline, schedule baseline, performance measurement baseline, etc. 

14.10 Best practices 

Techniques that agencies may use to help detect problems in the acquisition, management, and administration 
of service contracts. Best practices are practical techniques gained from experience that have been shown to 
produce best results. 

14.11 Beta testing 

Pre-release testing in which a sampling of the intended customer base tries out the product. 

14.12 Bottom-up cost estimate 

The approach to making a cost estimate or plan in which detailed estimates are made for every task shown 
in the work breakdown structure and then summed to provide a total cost estimate or plan for the project. 

14.13 Brainstorming 

The unstructured and dynamic generation of ideas by a group of people where anything and everything is 
acceptable, particularly useful in generating a list of potential project risks. 

14.14 Budget 

Generally refers to a list of all planned expenses and revenues. 
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14.15 Budgeted cost of work performed (BCWP) 

Measures the budgeted cost of work that has actually been performed, rather than the cost of work scheduled. 

14.16 Budgeted cost of work scheduled (BCWS) 

The approved budget that has been allocated to complete a scheduled task, or work breakdown structure 
(WBS) component, during a specific time period. 

14.17 Business analysis 

Is the set of tasks, knowledge, and techniques required to identify business needs and determine solutions 
to business problems. Solutions often include a systems development component, but may also consist of 
process improvement or organizational change. 

14.18 Business area 

The part of the organization containing the business operations affected by a program or project. 

14.19 Business case 

A document developed towards the end of the concept phase, to establish the merits and desirability of the 
project and justification for further project definition. 

14.20 Business needs 

The requirements of an enterprise to meet its goals and objectives. 

14.21 Business operations 

The ongoing recurring activities involved in the running of a business for the purpose of producing value for 
the stakeholders. They are contrasted with project management, and consist of business processes. 

14.22 Business process 

A collection of related, structured activities or tasks that produce a specific service or product (serve a partic- 
ular goal) for a particular customer or customers. There are three types of business processes: management 
processes, operational processes, and supporting processes. 

14.23 Case study 

A research method which involves an in-depth, longitudinal examination of a single instance or event: a case. 
They provide a systematic way of looking at events, collecting data, analyzing information, and reporting 
the results. 
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14.24 Champion 

An end user representative, often seconded into a project team. Someone who acts as an advocate for a 
proposal or project. 

14.25 Change control 

A general term describing the procedures used to ensure that changes (normally, but not necessarily, to IT 
systems) are introduced in a controlled and coordinated manner. Change control is a major aspect of the 
broader discipline of change management. 

14.26 Change management 

The formal process through which changes to the project plan are approved and introduced. 

14.27 Change order 

A document that authorizes a change in some aspect of the project. 

14.28 Change request 

A request needed to obtain formal approval for changes to the scope, design, methods, costs, or planned 
aspects of a project. Change requests may arise through changes in the business or issues in the project. 
Change requests should be logged, assessed and agreed on before a change to the project can be made. 

14.29 Child activity 

Subordinate task belonging to a parent task existing at a higher level in the work breakdown structure. 

14.30 Client/customers 

The person or group that is the direct beneficiary of a project or service is the client/customer. These 
are the people for whom the project is being undertaken (indirect beneficiaries are stakeholders). In many 
organizations, internal beneficiaries are called clients and external beneficiaries are called customers, but 
this is not a hard and fast rule. 

14.31 Constraints 

Constraints are limitations that are outside the control of the project team and need to be managed around. 
They are not necessarily problems. However, the project manager should be aware of constraints because 
they represent limitations that the project must execute within. Date constraints, for instance, imply that 
certain events (perhaps the end of the project) must occur by certain dates. Resources are almost always a 
constraint, since they are not available in an unlimited supply. 
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14.32 Critical path 

The critical path is the sequence of activities that must be completed on schedule for the entire project to be 
completed on schedule. It is the longest duration path through the workplan. If an activity on the critical 
path is delayed by one day, the entire project will be delayed by one day (unless another activity on the 
critical path can be accelerated by one day). 

14.33 Closeout 

The completion of all work on a project. 

14.34 Communication plan 

A statement of project's stakeholders' communication and information needs. 

14.35 Concept phase 

The first phase of a project in the generic project lifecycle, in which the need is examined, alternatives are 
assessed, the goals and objectives of the project are established and a sponsor is identified. 

14.36 Confidence level 

A level of confidence, stated as a percentage, for a budget or schedule estimate. The higher the confidence 
level, the lower the risk. 

14.37 Conflict management 

Handling of conflicts between project participants or groups in order to create optimal project results. 

14.38 Conflict resolution 

To seek a solution to a problem, five methods in particular have been proven through confrontations, com- 
promise, smoothing, forcing and withdrawal. 

14.39 Constraints 

Constraints are limitations that are outside the control of the project team and need to be managed around. 
They are not necessarily problems. However, the project manager should be aware of constraints because 
they represent limitations that the project must execute within. Date constraints, for instance, imply that 
certain events (perhaps the end of the project) must occur by certain dates. Resources are almost always a 
constraint, since they are not available in an unlimited supply. 

14.40 Contingencies 

A Contingency is the planned allotment of time and cost for unforeseeable elements with a project. Including 
contingencies will increase the confidence of the overall project. 
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14.41 Control 

The process of comparing actual performance with planned performance, analyzing the differences, and 
taking the appropriate corrective action. 

14.42 Costs 

The cost value of project activity. 

14.43 Costs budgeting 

The allocation of cost estimates to individual project components. 

14.44 Cost overrun 

The amount by which actual costs exceed the baseline or approved costs. 

14.45 Crashing 

The process of reducing the time it takes to complete an activity by adding resources. 

14.46 Critical 

An activity or event that, if delayed, will delay some other important event, commonly the completion of a 
project or a major milestone in a project. 

14.47 Critical path method (CPM) 

A mathematically based modeling technique for scheduling a set of project activities, used in project man- 
agement . 

14.48 Critical chain project management (CCPM) 

A method of planning and managing projects that puts more emphasis on the resources required to execute 
project tasks. 

14.49 Critical success factors 

The key factors that are deemed critical to the success of the project. The nature of these factors will govern 
the response to conflicts, risks and the setting of priorities. 

14.50 Culture 

A person's attitudes arising out of their professional, religious, class, educational, gender, age and other 
backgrounds. 
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14.51 Customer 

See client. 

14.52 Deliverable 

A deliverable is any tangible outcome that is produced by the project. All projects create deliverables. These 
can be documents, plans, computer systems, buildings, aircraft, etc. Internal deliverables are produced as a 
consequence of executing the project and are usually needed only by the project team. External deliverables 
are those that are created for clients and stakeholders. Your project may create one or many deliverables. 

14.53 Dependency 

Dependencies on a project are the relationships between activities whereby one activity must do something 
(finish-to-start) before another activity can do something (start-to-finish). 

14.54 Duration 

The duration of a project's terminal element is the number of calendar periods it takes from the time the 
execution of element starts to the moment it is completed. 

14.55 Earned value management (EVM) 

A project management technique for measuring project progress in an objective manner, with a combination 
of measuring scope, schedule, and cost in a single integrated system. 

14.56 Earned schedule (ES) 

An extension to earned value management (EVM), which renames two traditional measures, to indicate 
clearly they are in units of currency or quantity, not time. 

14.57 Estimation 

In project management it is the processes of making accurate estimates using the appropriate techniques. 

14.58 Event chain diagram 

A diagram that show the relationships between events and tasks and how the events affect each other. 

14.59 Event chain methodology 

An uncertainty modeling and schedule network analysis technique that is focused on identifying and managing 
events and event chains that affect project schedules. 
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14.60 Float 

In a project network is the amount of time that a task in a project network can be delayed without causing 
a delay to subsequent tasks and or the project completion date. 

14.61 Functional manager 

The functional manager is the person you report to within your functional organization. Typically, this is 
the person who does your performance review. The project manager may also be a functional manager, 
but he or she does not have to be. If your project manager is different from your functional manager, your 
organization is probably utilizing matrix management. 

14.62 Gantt, Henry 

An American mechanical engineer and management consultant, who developed the Gantt chart in the 1910s. 

14.63 Gantt chart 

A Gantt chart is a bar chart that depicts activities as blocks over time. The beginning and end of the block 
correspond to the beginning and end-date of the activity. 

14.64 Goal 

An objective that consists of a projected state of affairs which a person or a system plans or intends to 
achieve or bring about a personal or organizational desired end-point in some sort of assumed development. 
Many people endeavor to reach goals within a finite time by setting deadlines. 

14.65 Goal setting 

Involves establishing specific, measurable and time targeted objectives. 

14.66 Graphical evaluation and review technique (GERT) 

A network analysis technique that allows probabilistic treatment of both network logic and activity duration 
estimated. 

14.67 Hammock activity 

A schedule (project management) or project planning term for a grouping of subtasks that hangs between 
two end dates it is tied to. or the two end events it is fixed to. 

14.68 ISO 10006 

A guideline for quality management in projects, is an international standard developed by the International 
Organization for Standardization. 
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14.69 Issue 

An issue is a major problem that will impede the progress of the project and that can't be resolved by the 
project manager and project team without outside help. Project managers should proactively deal with 
issues through a defined issues management process. 

14.70 Kickoff meeting 

The first meeting with the project team and the client of the project. 

14.71 Level of effort (LOE) 

Is qualified as a support type activity which doesn't lend itself to measurement of a discrete accomplishment. 
Examples of such an activity may be project budget accounting, customer liaison, etc. 

14.72 Life cycle 

Life cycle refers to the process used to build the deliverables produced by the project. Every project 
has an inception, a period during which activities move the project toward completion, and a termination 
(either successful or unsuccessful). Taken together, these phases represent the path a project takes from the 
beginning to its end and are generally referred to as the project life cycle. The project life cycle is often 
formally divided into phases that describe common activities as the project matures. 

14.73 Management 

In business and human organization activity is simply the act of getting people together to accomplish 
desired goals. Management comprises planning, organizing, staffing, leading or directing, and controlling an 
organization (a group of one or more people or entities) or effort for the purpose of accomplishing a goal. 

14.74 Management process 

A process of planning and controlling the performance or execution of any type of activity. 

14.75 Motivation 

Is the set of reasons that determines one to engage in a particular behavior. 

14.76 Milestone 

A milestone is a scheduling event that signifies the completion of a major deliverable or a set of related 
deliverables. A milestone, by definition, has duration of zero and no effort. There is no work associated with 
a milestone. It is a flag in the work plan to signify that some other work has completed. Usually, a milestone 
is used as a project checkpoint to validate how the project is progressing. In many cases there is a decision, 
such as validating that the project is ready to proceed further, that needs to be made at a milestone. 
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14.77 Objective 

An objective is a concrete statement that describes what the project is trying to achieve. The objective 
should be written at a low level, so that it can be evaluated at the conclusion of a project to see whether 
it was achieved. Project success is determined based on whether the project objectives were achieved. A 
technique for writing an objective is to make sure it is specific, measurable, acceptable, realistic, and time 
based (SMART). 

14.78 Operations management 

An area of business that is concerned with the production of good quality goods and services, and involves 
the responsibility of ensuring that business operations are efficient and effective. It is the management of 
resources, the distribution of goods and services to customers, and the analysis of queue systems. 

14.79 Organization 

A social arrangement which pursues collective goals, which controls its own performance, and which has a 
boundary separating it from its environment. 

14.80 Planning 

Planning in project management consists of processes that involve formulating and revising project goals 
and objectives and creating the project management plan that will be used to achieve the goals the project 
was undertaken to address. Planning involves determining alternative courses of action and selecting from 
among the best of those to produce the project's goals. 

14.81 Process 

An ongoing collection of activities, with an inputs, outputs and the energy required to transform inputs to 
outputs. 

14.82 Program 

A program is the umbrella structure established to manage a series of related projects. The program does 
not produce any project deliverables. The project teams produce them all. The purpose of the program is 
to provide overall direction and guidance, to make sure the related projects are communicating effectively, 
to provide a central point of contact and focus for the client and the project teams, and to determine how 
individual projects should be defined to ensure that all the work gets completed successfully. 

14.83 Program management 

The process of managing multiple ongoing inter-dependent projects. An example would be that of designing, 
manufacturing and providing support infrastructure for an automobile manufacturer. 

14.84 Program manager 

A program manager is the person with the authority to manage a program. (Note that this is a role. 
The program manager may also be responsible for one or more of the projects within the program.) The 
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program manager leads the overall planning and management of the program. All project managers within 
the program report to the program manager. 

14.85 Project 

A project is a temporary endeavor undertaken to accomplish a unique product or service with a defined start 
and end point and specific objectives that, when attained, signify completion. 

14.86 Project definition (project charter) 

Before you start a project, it is important to know the overall objectives of the project, as well as the scope, 
deliverables, risks, assumptions, project organization chart, etc. The project definition (or project charter) 
is the document that holds this relevant information. The project manager is responsible for creating the 
project definition. The document should be approved by the sponsor to signify that the project manager 
and the sponsor are in agreement on these important aspects of the project. 

14.87 Project manager 

The project manager is the person with the authority to manage a project. The project manager is 100 
percent responsible for the processes used to manage the project. He or she also has people management 
responsibilities for team members, although this is shared with the team member's functional manager. 
The processes used to manage the project include defining the work, building the work plan and budget, 
managing the work plan and budget, scope management, issues management, risk management, etc. 

14.88 Project management 

Project management is the application of knowledge, skills, tools, and techniques applied to project activities 
in order to meet or exceed stakeholder needs and expectations from a project. 

14.89 Project management body of knowledge (PMBOK) 

The sum of knowledge within the profession of project management that is standardized by ISO. 

14.90 Project management professional 

A certificated professional in project management. 

14.91 Project management software 

A type of software, including scheduling, cost control and budget management, resource allocation, collabo- 
ration software, communication, quality management and documentation or administration systems, which 
are used to deal with the complexity of large projects. 
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14.92 Project phase 

A phase is a major logical grouping of work on a project. It also represents the completion of a major 
deliverable or set of related deliverables. On an IT development project, logical phases might be planning, 
analysis, design, construct (including testing), and implementation. 

14.93 Project plan 

A formal, approved document used to guide both project execution and project control. The primary uses 
of the project plan are to document planning assumptions and decisions, facilitate communication among 
stakeholders, and document approved scope, cost, and schedule baselines. A project plan may be summary 
or detailed. 

14.94 Project planning 

A part of project management, which relates to the use of schedules such as Gantt charts to plan and 
subsequently report progress within the project environment. 

14.95 Project team 

The project team consists of the full-time and part-time resources assigned to work on the deliverables of the 
project. They are responsible for understanding the work to be completed; completing assigned work within 
the budget, timeline, and quality expectations; informing the project manager of issues, scope changes, and 
risk and quality concerns; and proactively communicating status and managing expectations. 

14.96 Quality 

The standards and criteria to which the project's products must be delivered for them to perform effectively. 
First, the product must perform to provide the functionality expected, and to solve the problem, and deliver 
the benefit and value expected of it. It must also meet other performance requirements, or service levels, such 
as availability, reliability and maintainability, and have acceptable finish and polish. Quality on a project is 
controlled through quality assurance (QA) which is the process of evaluating overall project's performance 
on a regular basis to provide confidence that the project will satisfy the relevant quality standards. 

14.97 Requirements 

Requirements are descriptions of how a product or service should act, appear, or perform. Requirements 
generally refer to the features and functions of the deliverables you are building on your project. Requirements 
are considered to be a part of project scope. High-level scope is defined in your project definition (charter). 
The requirements form the detailed scope. After your requirements are approved, they can be changed 
through the scope change management process. 

14.98 Resources 

Resources are the people, equipment, and materials needed to complete the wrok of the project. 
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14.99 Risk 

There may be potential external events that will have a negative impact on your project if they occur. Risk 
refers to the combination of the probability the event will occur and the impact on the project if the event 
occurs. If the combination of the probability of the occurrence and the impact to the project is too high, 
you should identify the potential event as a risk and put a proactive plan in place to manage the risk. 

14.100 Risk management planning 

The process that determines how risks will be managed for a project. It describes how risks are defined, 
monitored, and controlled throughout the project. 

14.101 Schedule development 

This process calculates and prepares the schedule of project activities, which becomes the schedule baseline. 
It determines activity start and finish dates, finalizes activity sequences and durations, and assigns resources 
to activities. 

14.102 Scope 

Scope is the way you describe the boundaries of the project. It defines what the project will deliver and 
what it will not deliver. High-level scope is set in your project definition (charter) and includes all of your 
deliverables and the boundaries of your project. The detailed scope is identified through your business 
requirements. Any changes to your project deliverables, boundaries, or requirements would require approval 
through scope change management. 

14.103 Scope creep 

Refers to uncontrolled changes in a project's scope. This phenomenon can occur when the scope of a project 
is not properly defined, documented, or controlled. It is generally considered a negative occurrence that is 
to be avoided. 

14.104 Six sigma 

A business management strategy, originally developed by Motorola, that today enjoys widespread application 
in many sectors of industry. 

14.105 Sponsor (executive sponsor and project sponsor) 

The sponsor is the person who has ultimate authority over the project. The executive sponsor provides 
project funding, resolves issues and scope changes, approves major deliverables, and provides high-level 
direction. He or she also champions the project within the organization. Depending on the project and the 
organizational level of the executive sponsor, he or she may delegate day-to-day tactical management to a 
project sponsor. If assigned, the project sponsor represents the executive sponsor on a day-to-day basis and 
makes most of the decisions requiring sponsor approval. If the decision is large enough, the project sponsor 
will take it to the executive sponsor. 
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14.106 Stakeholder 

Specific people or groups who have a stake in the outcome of the project are stakeholders. Normally stakehold- 
ers are from within the company and may include internal clients, management, employees, administrators, 
etc. A project can also have external stakeholders, including suppliers, investors, community groups, and 
government organizations. 

14.107 Steering committee 

A steering committee is usually a group of high-level stakeholders who are responsible for providing guidance 
on overall strategic direction. They don't take the place of a sponsor but help spread the strategic input and 
buy-in to a larger portion of the organization. The steering committee is especially valuable if your project 
has an impact in multiple organizations because it allows input from those organizations into decisions that 
affect them. 

14.108 Systems development lifecycle (SDLC) 

Is any logical process used by a systems analyst to develop an information system, including requirements, 
validation, training, and user ownership. An SDLC should result in a high quality system that meets 
or exceeds customer expectations, within time and cost estimates, works effectively and efficiently in the 
current and planned information technology (IT) infrastructure, and is cheap to maintain and cost-effective 
to enhance. 

14.109 Tasks 

In project management a task is an activity that needs to be accomplished within a defined period of time. 

14.110 Task analysis 

The analysis or a breakdown of exactly how a task is accomplished, such as what sub-tasks are required. 

14.111 Timeline 

A graphical representation of a chronological sequence of events also referred to as a chronology. It can also 
mean a schedule of activities, such as a timetable. 

14.112 Triple constraint 

Triple constraint is called the scope triangle or the quality triangle. The triangle illustrates the relationship 
between three primary forces in a project. Project scope, time and cost-Project quality is affected by 
balancing these three factors. 

14.113 Work 

In project management is the amount of effort applied to produce a deliverable or to accomplish a task (a 
terminal element). 
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14.114 Work breakdown structure (WBS) 

A task oriented family tree of activities which organizes, defines and graphically dispays the total work to 
be accomplished in order to achieve the final objectives of a project. It is a system for sub-dividing a project 
into manageable work packages. 

14.115 Work package 

A deliverable at the lowest level of a work breakdown structure (WBS). They are a group of related tasks 
that are defined at the same level within the WBS. 



14.116 Work plan (schedule) 



The project work plan tells you how you will complete the project. It describes the activities required, the 
sequence of the work, who is assigned to the work, an estimate of how much effort is required, when the work 
is due, and other information of interest to the project manager. The work plan allows the project manager 
to identify the work required to complete the project and also allows the project manager to monitor the 
work to determine whether the project is on schedule. 
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